RGB pixel Kerstboom met auto mapping

[Sgrovert]

Al enige jaren ben ik bezig met het creëren van een kerstboom. In 2016 heb ik mijn kerstboom in de tuin gepland en elk jaar is er weer extra verlichting voor het vullen van de boom nodig.
In 2018 zijn er voor het eerst adresseerbare leds in de boom gehangen en sinds die tijd speel ik met idee van een automatische 3d mapping zodat er animaties over de boom afgespeeld kunnen worden.
Het plan is om dit jaar uit te breiden naar 500 pixels en deze mbv. een webcam te mappen.

---

Hardware

Als pixels gebruik ik ws2811 leds in strings van 50 leds. In de HSV kleurenruimte moeten deze per 2 strings (100 leds) opnieuw met 5 Volt gevoed worden. Per 50 leds moet de voeding van 1A kunnen leveren. Voor het aansturen van de leds is een Arduino meestal het makkelijkst. Bij het genereren van de animaties denk ik dat een Arduino te weinig geheugen zal hebben en zal het projectje waarschijnlijk naar een esp32 gezet worden. Bij andere projecten heb ik gemerkt dat een raspberry pi geen goede keuze is om deze leds aan te sturen. Bij grotere led strings haalt een pi de timing niet altijd, omdat de processor een ander process tussendoor kan draaien. Het protocol voor ws2811/12 leds is time sensitive en op de Arduino / esp32 werkt het veel stabieler. Indien er interesse is kan ik informatie over de gebruikte stekkers en kabelboom geven.

---

Software

Voor de software heb ik nog geen definitieve keuzes, behalve dat ik het project in python ga maken.
Voor het berekenen van de pixel locaties wil ik uit verschillende hoeken met een webcam foto's van de pixel locaties maken. Vanuit verschillende hoeken wil ik een serie foto's maken waarbij in elke foto andere leds branden.

Matt Parker

Afgelopen jaren heeft Matt Parker een paar video's op youtube gezet met een vergelijkbaar idee.
Ik wil het mappen van de pixels iets generieker aanpakken door de pixels vanuit willekeurige camera posities te mappen.

Eerste generatie boom met pixel mapping.	Error Correctie op de pixel locaties

---

Pixel mapping

Waar Matt zijn boom 90 graden kon draaien is dat voor mijn boom geen optie. De boom zit vast in de grond en door planten en het huis kan ik niet vanuit alle kanten een mapping maken.
Theoretisch heb ik wel enkele gegevens waarmee ik aan de slag kan.
- Pixels zitten max 10 cm uit elkaar. Op overgangen tussen strings kan dit groter zijn omdat pixels met connectoren ertussen verder uit elkaar zitten. (afstand tussen pixel 50 en 51, 100 en 101 etc).
- Pixels zitten op een vaste plek in de boom. Afhankelijk van de hoek van de camera kunnen 2 naastliggende pixels gezien worden als 2 individuele pixels, of als 1 pixel wat precies op dezelfde plek ligt.
- Uit eerdere jaren weet ik dat pixels eigenlijk altijd wel minimaal 5 cm uit elkaar zitten en max 10. De afstand is constant genoeg in alle richtingen om de gemaakte foto's te kunnen schalen.
- Afhankelijk van hoe ver 2 pixels bij 2 verschillende camera posities uit elkaar liggen moet het mogelijk zijn om te bepalen waar de camera heen verplaatst is.
Als 2 pixels op foto A 10 cm uit elkaar liggen is de foto "loodrecht" op de pixels genomen. Als op foto B de 2 pixels precies "achter" elkaar liggen, dan is de foto van de zijkant genomen. De camera is dan dus 90 graden verplaatste tussen beide foto's


Bovenstaande afbeelding is een schets van hoe ik de automatische camera mapping wil maken. In de afbeelding staan 4 pixels/leds (rood, groen, blauw en geel).
Er zijn 5 camera posities geschetst (1, 2, 3, 4 en alfa). Vanaf elke positie heb ik een loodrechte projectie van de leds genomen en deze projectie als lijn onder de afbeelding gezet.
Enkele gedachten experimenten bij deze afbeelding :
Bij positie 1 en 3 vallen de rode en blauwe led precies op dezelfde positie. Hieruit valt af te lijden dat de camera precies op de lijn rood/blauw staat. Positie 1 en 3 zijn precies gespiegeld wat betekend dat de camera 180 graden verplaatst is.
Hetzelfde geld voor positie 2 en 4. Deze projecties zijn ook gespiegeld.
Vergelijken we positie 1 met 2, dan valt op dat in beeld 1 rood en blauw dezelfde plek hebben, terwijl ze in beeld 2 ver uit elkaar liggen.
Lijn alfa (paarse lijn) is getekend omdat ik in praktijk willekeurige hoeken wil kunnen gebruiken. Vergelijken we lijn 2 en lijn alfa, dan zien we dat de leds op beide lijnen op totaal andere plekken liggen. Het verschil van de positie van de led correspondeert met hoek alfa. Door naar het verschuiven van de leds in beeld 2 en alfa te kijken, moet het mogelijk zijn om de hoek te berekenen.
Als de hoek tussen 2 camera onderling bekend is, is het met voldoende kanten mogelijk om alle camera posities terug te rekenen. Als de posities van de camera berekend zijn kan daarna de exacte posities van alle leds berekend worden.

Uiteindelijk zal de software een paar flinke matrix berekening krijgen en de uiteindelijke posities van de led een gemiddelde positie zijn. Factoren als leds die verplaatsen door de wind, vervormingen van de camera lens etc. zullen uitmiddelen. Ik verwacht dat de aanname dat het camera beeld een "perfecte" loodrechte 2d projectie is geen grote invloed op de eindresultaat heeft.

---

Kerstboom

Nu is bovenstaand een redelijk technisch verhaal. Voor de lief hebber nog wat foto's van de knutsel van afgelopen jaren.

2017 Boom 1 jaar met een standaard led verlichting

2018 Uitbreiding met 50 pixels

2019 Boom word groter. Uitgebreid met 4 led bollen.

2020 Weinig knutsel tijd boom uitgebreid met een standaard verlichting

2021 Uitbreiding naar 250 pixels. mrs Sgrovert heeft geholpen met de versiering.

Mochten mensen zin hebben om mee te knutselen, een setje pixels + adapter + Arduino is te bestellen voor zo'n €25,- . Bij interesse kunnen we de code gezamenlijk maken. Ik heb namelijk wel ideeën over het mappen van de pixels, maar nog niet nagedacht over animaties. Ook kunnen ander opensource projecten interessant als basis zijn.

[Sgrovert]

Vanavond eerste opzetje gemaakt.
Ik had nog een setje ESP8266 liggen.
Ondanks dat deze 3.3 V zijn kan je hier op korte afstanden vrij probleemloos 5V WS2811 pixels mee aansturen. Het eerste pixel verhoogt de spanning naar 5V, waardoor er later in de chain ook geen problemen ontstaan als het werkt.

Op de ESP heb ik standaard MicroPython gezet. Dit heeft wel even geduurd omdat mijn PC de ESP niet over de com poort zag. Uiteindelijk na lang zoeken gevonden dat het aan de kabel ligt. De kabel die ik gebruikte had geen data paren .
Voor de ESP8266 heeft MicroPython standaard de Neopixel library. Deze is was minder uitgebreid dan Fastled, maar voor een eerste test prima bruikbaar. Op de ESP staat nu een klein scriptje dat een json van stdin inlaad.

JSON:

{"rgb": [{"r":255,"g":0,"b":0},{"r":0,"g":255,"b":0},{"r":0,"g":0,"b":255}]}

Dit voorbeeld is voor 3 pixels, maar kan natuurlijk naar het aantal pixels in de string uitgebreid worden.

Naast de code op de ESP heb ik ook een python script op de laptop gemaakt. Als test stuurt deze 255 frames van 50 pixels over een seriële verbinding. Dit heb ik getimed op 47 seconden wat neerkomt op 5 frames per seconde. Voor de eerste test is dit goed genoeg. Theoretisch zou er 600 FPS mogelijk zijn, maar optimalisaties kunnen prima als het eerste proto type klaar is.

De volgende stap word het automatiseren van het maken van foto's. Zodra deze er zijn plaats ik de volgende update.

[Voor 4% gewijzigd door Sgrovert op 26-10-2022 02:21]

[Sgrovert]

Vandaag heb ik de webcam aan de praat gekregen. De afbeelding hierboven bevat 8 opnames. Iedere led in de afbeelding heeft een uniek patroon van aan / uit.
In totaal heb ik 50 leds gebruikt. Elke led heeft een random unieke waarde tussen de 16 en 255 gekregen. Vervolgens heb ik deze in een byte omgezet en bij elk van de 8 beelden een nieuwe bit gepakt. Als de bit hoog was, is de led aan, is de bit laag, is de led uit.
Bij de beelden heb ik eerst een ground image met alle leds uit gemaakt. Deze ground is van elke afbeelding afgetrokken, waardoor alleen het licht van de leds overblijft.
Uit de serie van 8 afbeeldingen moet het nu mogelijk zijn om de individuele leds terug te vinden. Hiervoor wil ik een cluster algoritme zoals bv. k-means gaan gebruiken. Met een k van 50 of 51 verwacht ik dat het center van elk cluster een led zal representeren. Door het toewijzen van de random getallen, is het onwaarschijnlijk dat 2 naastliggende leds ongeveer dezelfde sequentie van aan/uit volgen.
Nadat de clusters gevonden zijn zal voor elk cluster gekeken worden naar het patroon van veel / weinig licht. Dit patroon is bv. 01011101 . Deze match 91. Daarna kan opgezocht worden welke led number 91 toegewezen had en is de positie van de betreffende led bekend.

Bovenstaande afbeelding is in een tijdbestek van 10 seconden gemaakt. Bij het uitbreiden naar 500 leds zijn er waarschijnlijk 2 afbeeldingen meer nodig. Dit geeft namelijk 1024 unique sequenties. Het inmeten van een nieuwe camera positie zal naar verwachting snel te doen moeten zijn, mits het clusteren de gewenste detectie geeft.

[Sgrovert]

Afgelopen dagen ben ik bezig geweest met de image processing. Ik ben iets minder thuis in de libraries voor de matrix berekeningen waardoor de progressie iets langzamer is.
Voor het vinden van de leds wil ik zo min mogelijk hard coded thresholds gebruiken. Mijn boven beschreven algoritme lijkt vrij goed te werken. De huidige implementatie is als volgt.
Elke led krijg een uniek random nummer toegewezen. Dit nummer word omgezet in 8 bits. Vervolgens worden er 10 foto's gemaakt.
Foto 1 -> alle leds uit. Dit is een reference base image
Foto 2 -> Alle leds dit bit 1 hoog hebben gaan aan, alle andere uit.
Foto 3 -> Alle leds die bit 2 hoog hebben gaan aan, andere uit.
etc.
Als laatste word er een foto met alle leds aan gemaakt. Deze led gebruik ik alleen om achteraf visueel te kunnen controleren of de gevonden positief met de werkelijkheid kloppen.

Nadat de foto's gemaakt zijn worden de waarden van het base image van de "bit" foto's afgehaald. Hierdoor blijft alleen het licht van de leds over.
Van deze images maak ik voor elke pixel een array van 8 waarden aan, waarbij de waarde van elke foto in het array staat. Dit ziet er ongeveer als volgt uit

Elk pixel heeft 8 waardes. Hoe roder de kleur, hoe hoger de waarde. Het pixel op de bovenste rij krijgt binary value 00011110. Dit pixel hoort bij de led die random waarde 30 gekregen heeft.

Hhet Kmeans algoritme word gebruikt om 50 clusters van pixels te maken. Pixels die hetzelfde patroon van waardes volgen, komen bij elkaar in een groep te staan. Bij de eerste iteratie zijn er een paar zeer grote groepen. De meeste pixels in de afbeelding geven binary 00000000 daar er geen led op deze plek zit en het pixel donker blijft. Helaas geven de leds zelf wel strooilicht, waardoor dit niet makkelijk te filteren is.
Dit heb ik tijdelijk opgelost door na het berekenen van de clusters de grootste groep pixels weg te gooien, en opnieuw te cluseteren. Dit gaat door totdat elke groep minder dan 100 pixels heeft. Ondanks dat dit werkt, is het langzaam en zal de hardcoded 100 pixels niet voor elke camera een goede limiet zijn. Hier zal later een betere filtering voor bedacht moeten worden.

Na het Clusteren word voor elk cluster gekeken welke binary sequentie voor het cluster geld. Daarna word terug gezocht welke led deze sequentie had.

Dit is het resultaat van vandaag. Bij de gevonden clusters is het id van de led geprint. De ledstring begint rechtsonder, gaat naar boven, komt midden omlaag en gaat links weer naar boven. De id's van de leds lopen in volgorde netjes mee. Het lijkt dat het algoritme vrij goed werkt. Er zijn geen false positives. Wel zijn er een behoorlijk aantal clusters heel dicht bij elkaar. De blauwe punten zijn de centra van de clusters en in rood is het id geprint. Doordat deze zo dicht bij elkaar liggen staan de nummer over elkaar heen.
In praktijk verwacht ik dit ook. Het is niet aannemelijk dat alle leds vanuit 1 camera standpunt te zien zijn. Indien er 2 centra bij elkaar liggen en ook dezelfde led refereren is dit makkelijk samen te voegen tot 1 locatie.

[_ferry_]

Ik vind het originele product wat je in het tuincentrum ziet al een echt toffe gadget (en duur helaas ) Maar dat je het zelf ontwikkeld is helemaal knap. Succes!

[Sgrovert]

@_ferry_ dank voor het compliment.
Het product in de tuincentra is inderdaad vergelijkbaar alleen 4x duurder. Bij het zelf ontwikkelen ga ik wel een volledig 3d model maken. Mijn boom staat vrij en is van alle kanten zichtbaar. Van wat ik kan zien mappen de tuincentra producten maar van 1 kant. Tevens moet je bij die producten hopen dat de fabrikant de server online laat. Als de stekker er over een paar jaar uitgaat, zal de mapping ook niet meer werken.

---

Vandaag ben ik verder gegaan met het verbeteren van de led detectie. Het doel was een algoritme dat geen hardcoded 100 pixel limiet meer nodig had.
Dit is bereikt door een classificatie score aan de cluster toe te kennen. Deze score is een penalty welke aangeeft hoe goed de detectie van licht/donker is. Met het binair aanzetten van de led volgen alle pixels in een cluster hetzelfde patroon van licht, donker, donker, licht etc. Onderstaande afbeelding toont de waardes van de 8 frames voor 3 clusters.
De oranje lijn zijn de waardes van een laag scorend cluster. In 5 frames was de led aan (waarde 185) en in 3 frames was deze uit (waarde 12). Voor het berekenen van de score word eerst het gemiddelde van de hoge en lage waarde berekend. Vervolgens word van elke sample het verschil tussen zijn waarde en de lage of hoge waarde bepaald. Pixels die boven de gemiddelde waarde van alle 8 pixels zitten worden met hoog vergeleken, de andere pixels met laag. Het verschil tussen gemiddelde en pixel word gekwadrateerd en opgeteld voor alle 8 de punten. Hoe lager de score, hoe duidelijker het patroon van hoog laag.
De blauwe lijn de waardes van een ander laag scorend cluster. De min en max waarde zijn beide zeer laag ( 7 en 10 ), waardoor elk punt heel dicht bij een van beide ligt.
De groene lijn is een slecht scorend cluster. De lage waarde is ongeveer 25 en geld voor sample 2,3 en 4. De hoge waarde is 82 en geldig voor sample 0, 5 en 7 . Sample 1 en 6 wijken af van 82 en zorgen dat dit cluster een hoge score behaald. Waarschijnlijk bevat dit cluster meerdere leds of zitten er 2 leds dicht bij elkaar.

In dit voorbeeld is de oranje lijn een correct gedetecteerde led. De Blauwe lijn hoort bij een cluster waarvan de pixels in elk frame donker zijn. Dit cluster bevat allen background pixels en is dus geen led. Naast de score heeft elk cluster dan ook een andere hoeveelheid pixels. Het oranje cluster had 80 pixels, het blauwe had 16000 pixels. Hieruit kan ook geconcludeerd worden dat oranje waarschijnlijk een led is en blauw achtergrond.

Na het berekenen van de scores neem worden de 20% best scorende clusters gebruikt. Van deze clusters word het cluster met de minste pixels als led cluster aangemerkt. Het cluster met de meeste pixels word als achtergrond gezien. Van beide clusters worden de pixels uit de berekening gehaald waarna de overige pixels opnieuw geclusterd worden.
Met deze method word nu in 50 iteraties elke run 1 nieuwe led gedetecteerd. Indien de score grafiek lijkt op die een eerder gedetecteerde led word gekeken of beide clusters dicht bij elkaar liggen. Indien ja, worden deze clusters samen gevoegd.
Gisteren was het issue dat voor een aantal leds 2 centra gedetecteerd werden. Het samen voegen lost dit op. Het algoritme gaat door tot er 50 unieke leds gevonden zijn.


De linker afbeelding is gisteren gemaakt. Rechts is dezelfde brondata, maar met de nieuwe detectie. In de nieuwe detectie is het issue van dubbele detectie opgelost. Ook zijn er in totaal meer leds juist geclassificeerd. Het algoritme lijkt beter te werken als de leds verder uit elkaar zitten. Led 0 t/m 16 en 22 t/m 44 zitten netjes op een rij. Voor deze rijen heeft de detectie vrij aardig gewerkt. De overige leds zitten dichter bij elkaar. Hier is detectie moeilijker door strooilicht.
Sommige van de gedetecteerde leds zijn met het oog moeilijker zichtbaar. led 38 en 39 zitten achter een hoekje. Deze zijn gevonden zonder direct zicht. led 13 zit achter een plastic bak. Het plastic was licht doorschijnend waardoor ook deze led gevonden is.

Met het algoritme van vandaag is 60% van de leds op de juiste plek gedetecteerd. Voor de initiële implementatie is dit voldoende. Een aantal van de missende leds zijn makkelijk te vinden daar de positie van de buren bekend is. Ook zal zodra alles in de boom hangt, niet elke led zichtbaar zijn, waardoor 100% detectie niet mogelijk is. In de boom hangen de leds ook netter op een rij en zijn er minder reflecties van de achtergrond.
Ik verwacht dat als er van meerdere kanten gefotografeerd worden, elke led wel in 1 of meer afbeeldingen gevonden zal worden. Bij een detectie van meer dan 50% zitten er in afbeeldingen uit 2 verschillende hoeken altijd wel 2 leds die in beide afbeelding juist gedetecteerd zijn. Ook kan er met behulp van de score en de scores van de buur leds een betrouwbaarheid van de led positie bepaald worden. Door een aantal betrouwbare led posities welke in 2 camera standpunten zitten te vergelijken, moet het mogelijk zijn om te bepalen hoe de camera verplaatst is.

---

Kwa performance is de huidige code in een redelijke tijd uit te voeren. Om snel te testen heb ik binnen de webcam een window van 190 * 330 pixels ingesteld. Dit is precies de uitsnede van hoe de leds binnen de afbeelding passen. Het maken van de afbeeldingen kost een paar seconden wat niet wezenlijk anders is dan het maken van een volledig beeld. Op deze kleine afbeeldingen kost het detecteren van de leds 40 seconden.
Voor een volledige afbeelding zullen de eerste iteraties significant meer tijd kosten, maar ik verwacht dat er in totaal niet meer dan 2 minutes processing tijd nodig is.

[Voor 5% gewijzigd door Sgrovert op 29-10-2022 21:03]

[Sgrovert]

Afgelopen dagen is er niet veel te melden geweest. Dat betekend overigens niet dat er geen vooruitgang is.
Ik heb buiten even een testopstelling gemaakt en vanuit verschillende hoeken een opname gemaakt. Helaas zijn niet alle opnames evengoed gelukt en kom ik er bij het processen achter dat ik bepaalde data mis.
Van elke afbeelding zijn de leds bepaald. Deze heb ik proberen te plotten op een 3D kubus. Hier begon de voortgang te stagneren. Ik heb tot nog toe geen fijne library kunnen vinden om makkelijk een 3D plot te maken, en deze plot te kunnen draaien met de muis. Ook heb ik in mijn opnames de hoeken 0 , 45 , 90 en 240 graden gebruikt. Wil ik netjes op een kubus plotten was het handig geweest om het setje 0 / 180 of 90 / 270 te hebben. Ook is de opname van 90 graden niet helemaal lekker en zijn er maar enkele leds betrouwbaar gevonden.
In de plot zijn de rode punten de 90 graden opname, de blauwe punten zijn 240 graden. De groene lijnen verbinden overeenkomstige leds in beide opnames.

De lijnen groene lijnen lopen aardig parallel.

Heeft iemand een tip voor een goede library om dit soort plots makkelijk te kunnen maken? Om een of andere reden faden mijn lijnen weg.

Naast het maken van de plots, ben ik ook de wiskunde aan het uitwerken om de camera hoeken te kunnen bepalen. Hier binnenkort meer over. Dit is iets wat ik al lang niet meer gedaan heb.

[Batino]

Gaaf project! Heb je al naar de matplotlib library gekeken, deze heeft ook de mogelijkheid relatief makkelijk in 3D te plotten, waarbij je de figuren ook kunt draaien en evt. kan zoomen.

[Horla]

Misschien eens zoeken of niemand al eens Twinkly heeft gereverse engineerd?

[Sgrovert]

Twinkly bied inderdaad vergelijkbare functionaliteit. Van de filmpjes in de tuincentra lijkt het erop dat er met een app op de telefoon een opname gemaakt word vanaf 1 kant, en vervolgens de leds gemapped worden naar een 2d / 3d representatie. Hierin is het mij niet helemaal duidelijk of er ook een echte 3d mapping inzit en hoe de gebruiker moet filmen om alle pixels van alle kanten te mappen. Uit de filmpjes lijkt dit product op hetzelfde principe de locatie van de leds te vinden. Elke led heeft zijn unieke patroon en dit word met beeldanalyse terug gezet naar posities.

Batino schreef op maandag 7 november 2022 @ 13:28:
Gaaf project! Heb je al naar de matplotlib library gekeken

Deze was ik mee begonnen, maar ik heb niet (snel) gevonden hoe ik de figuur met de muis kan roteren. Om snel een proto type in elkaar te zetten pruts ik meestal niet langer dan half met een library voordat ik een andere probeer. Meestal eindig ik met een soort van copy paste van het internet die ongeveer doet wat ik in gedachten had. Mocht ik later nog een keer iets vergelijkbaars willen doen, develop ik de code wel even naar wat nette functies en zoek ik uit wat de parameters precies moeten zijn.

Eerder heb ik plaatjes gepost met een overlay van led posities op de achtergrond. Deze was toevallig wel met matplotlib gemaakt. In 3d kreeg ik het echter niet lekker snel werkend.

Ondertussen ben ik er wel achter dan mijn aanname dat een foto gelijk staat aan een loodrechte projectie een te grote versimpeling van de werkelijkheid is. Mijn huidige theorie is dat de camera als een punt in de ruimte gezien kan worden. Het licht van elk pixel op de sensor valt door de lens. Vanaf de lens kan je vervolgens een rechte lijn tekenen naar de positie waar het licht vandaan komt.
Dit model komt meer met de werkelijkheid overeen. 2 leds die vanaf de camera achter elkaar liggen schijnen hun licht immers op dezelfde pixel.
Vanwege de lenswerking komen pixels niet met een absolute locatie overeen, maar representeert elk pixel een richting van waaruit het licht komt. Het middelste pixel in de afbeelding is licht dat loodrecht op de camera valt. Hoe verder naar buiten, hoe groter de hoek het licht met de loodrechte stralen maakt. Elk pixel in de afbeelding geeft aan hoe groot de hoek is.

Vanavond matplotlib een nieuwe kans gegeven en van dit model een schets gemaakt.


In mijn huidige plan zitten de volgende aannames.

- Het centrum van de boom is op coördinaat 0,0
- De boom is ongeveer rond
- Alle leds zitten binnen de eenheidscirkel

P1 en P2 representeren 2 leds.
C1 en C2 zijn 2 willekeurige camera posities
Hoek α1, α2 β1 en β2 zijn bekend. Dit zijn de hoeken tussen de lijn camera -> led and camera -> oorsprong

Hoek Θ is de hoek tussen camera standpunt C1 en C2 en is de hoek die berekend moet worden.

Vanuit het model en de aannames kunnen we aan aantal zaken bepalen.
- De afstand van de camera naar de oorsprong is bekend. Deze kan bepaald worden door de grootste hoek die 2 leds maken te laten snijden aan weerszijden van de eenheidscirkel. (niet getekend)
- De exacte positie van C1 is inprincipe vij te kiezen. Als we aannemen dat het eerste beeld de boom recht van voren is kunnen we de positie van C1 bepalen.

Dit geeft in de afbeelding de volgende bekenden :
Oorsprong ( 0,0 )
C1 (0, -2)

α1, α2 β1 en β2 bekend.

De lijnen naar P1 en P2 snijden op of binnen de eenheidscirkel.

Wie kan helpen met de formule waarmee hoek Θ te bepalen is ?

Mijn gevoeld zegt dat Θ uit te drukken is in positie C1, 2 of 4 hoeken en afstand C2 oorsprong.

[Groentjuh]

Sgrovert schreef op maandag 7 november 2022 @ 23:01:
Twinkly bied inderdaad vergelijkbare functionaliteit. Van de filmpjes in de tuincentra lijkt het erop dat er met een app op de telefoon een opname gemaakt word vanaf 1 kant, en vervolgens de leds gemapped worden naar een 2d / 3d representatie. Hierin is het mij niet helemaal duidelijk of er ook een echte 3d mapping inzit en hoe de gebruiker moet filmen om alle pixels van alle kanten te mappen. Uit de filmpjes lijkt dit product op hetzelfde principe de locatie van de leds te vinden. Elke led heeft zijn unieke patroon en dit word met beeldanalyse terug gezet naar posities.

Er zijn 3d effecten, waarbij sommige het vrij duidelijk maken dat de mapping 3d is, indien je een 3d mapping hebt gedaan. Mapping begint met het mapping van de voorkant en daarna iedere keer zoveel mogelijk rode/oranje/gele leds in de volgende mapping krijgen. Zit niet perse een bepaalde verplichte route in die app. Als de app denkt te weten waar een zit, wordt hij groen tussen de mapping opnamens.

[Batino]

Standaard worden plots vaak als png gegenereerd, mijn gok zou zijn dat je in je IDE nog even een setting voor de graphics backend aan moet passen naar bv Qt om de matplotlib plots interactief te maken.

De som van de hoeken van een driehoek is altijd 180 graden, daardoor kunnen we Θ uitdrukken als Θ = 180 - α1 - β1

[Sgrovert]

Ik zie nu dat ik p1 een beetje ongelukkig gekozen heb.
Op de tekening lijken c1, p1 en c2 op een lijn te liggen, maar dit is alleen omdat ik dit toevallig getekend heb. p1 en p2 zijn beide willekeurig gekozen. Θ = 180 - α1 - β1 werkt helaas niet.

[Batino]

Aaah excuus, ik had ook wat beter kunnen lezen. Ik vraag mij dan af of Θ dan te berekenen is, ik heb nog een lijn getrokken van de oosprong O naar punt P1, zodat we het gebied omlijnt door C2, P2, C1, P1 opdelen in 2 driehoeken. Vervolgens hebben we minstens 3 gegevens (lengtes, hoeken of een combinatie) nodig per driehoek om de rest te kunnen berekenen. We kunnen de lengte vanaf de oorsprong O naar punt C1 eenvoudig berekenen, we hebben de hoek α1, maar dan mist er nog een hoek of lengte waarmee we de rest kunnen berekenen, en dus uiteindelijk Θ kunnen bepalen. Als er nog iets van symmetrie is die ik mis of je weet een van de andere variabelen te achterhalen, dan moet het zeker lukken!

[Sgrovert]

@Batino , thx voor het meedenken. Ik loop hier idd even een beetje vast. Ik kwam ook al tot de conclusie dat er te weinig gegevens zijn.
- C2 ligt op een cirkel om de Oorsprong met straal C2
- P1 lig binnen de eenheidscirkel. Op lijn C1, P1
De snijpunten van lijn C1 P1 met de eenheidscirkel kunnen bepaald worden. Op deze 2 punten hebben we 2 driehoeken waarvan we 3 gegevens hebben, 1 hoek en 2 lengtes. Op deze 2 punten is Θ te bepalen. De werkelijke waarde van Θ zal tussen deze 2 waarden in liggen. Kijkend naar de schets, zal P2 een vrij grote range opleveren. P1 ligt echter toevallig ongeveer op lijn C1 C2. Voor dit punt zullen de minimum en maximum dicht bij Θ = 180 - α1 - β1 .
Deze benadering zou voor elk punt bepaald kunnen worden. Hieruit zal ergens een hoek Θ uitkomen die voor alle punten werkt.

[Sgrovert]

Even een korte update.
Het project ligt niet stil, maar het vinden van de camera hoeken is lastig en kost veel tijd.
Het idee met de camera hoeken lijkt niet te werken. De schatting van de camera afstand is niet nauwkeurig genoeg, waardoor de variatie van hoeken te groot blijft. Ook is dit zeer lastig te debuggen.

Vandaag ben ik begonnen met het maken van nieuwe plotjes om te zien wat er in de data zit.

Testopstelling



In het plotje staat het bovenaanzicht van 2 camera posities (Rood en Blauw). De data komt van mijn eerder sessie waarbij ik in verschillende hoeken een test opstelling ingemeten heb. De camera afstand is automatisch geschaald, zodat alle "betrouwbare" led posities binnen de eenheidscirkel vallen. De lijnen zijn de lijnen vanaf de camera naar een gedetecteerde led. Waar de lijnen van 1 led elkaar kruisen is een gele stip getekend. Dit zou bij deze camerahoek de positie van de led zijn.

Op het eerste oog lijkt de positie van de leds vij aardig met de foto overeen te komen. Van beide camera posities weet ik dat deze ongeveer 45 graden uit elkaar gelegen hebben, en de posties van de genummerde leds komen ook aardig overeen met hoe de led keten gelegen heeft.
Nadere inspectie laat zien dat de gele punten niet precies op de kruising van de lijnen liggen .
Ik heb waarschijnlijk nog ergens een bug zitten.

In totaal heb ik als test uit 8 gelijkmatige richtingen vergelijkbare plaatjes gemaakt. Hieruit bleek van +45 en -45 graden heel veel matchende punten binnen de eenheidscirkel gaven. andere richtingen hadden veel minder of geen punten binnen de cirkel.
Het huidige plan is om 100 richtingen ofzo te testen, en de richting met de meeste punten binnen de cirkel is de meest waarschijnlijke camera hoek.

Binnenkort meer.

[Voor 4% gewijzigd door Sgrovert op 15-11-2022 01:27]

[Sgrovert]

Ik heb de "bug" gevonden.


De rode en blauwe lijnen zijn dezelfde als gisteren. De groene lijnen zijn de lijnen die gebruikt zijn om de snijpunten te berekenen. Deze lijnen lijken gespiegeld in de oorsprong.
De groene lijnen zijn geplot met functie :
y = (sin(α) * cam - x * cos(α - θ)) / (sin(α- θ))

α is de hoek tussen het pixel en de lijn Y = 0
θ is de rotatiehoek van de camera rond de oorsprong.
cam is de afstand van de camera tot de oorsprong.
Voor de rode lijn : θ = 0
Voor de baluwe lijn θ = 45°

Wie ziet de fout in de formule die ik gebruik?

Momenteel bepaal ik de snijpunten door de volgende 2 formules:
Rood
x * cos(α1) + y * sin(α1) - sim(α1) * cam1 = 0

Blauw
x * cos(α2 - θ) + y * sin(α2 - θ) - sim(α2) * cam2 = 0


Ondanks dat mijn huidige formules nog niet kloppen, heb ik wel een plaatje gemaakt dat de count van het aantal punten in de eenheidscirkel tegen hoek θ plot


Uit deze plaatjes blijkt dat met de huidige aanpak de camera hoek vrij aardig te schatten is. Op de X as staat hoek θ die blauw met rood maakt. Op de Y as de count van het aantal leds die in de eenheidscirkel liggen. Boven elke plot staat welke camerahoek ik op het oog geschat heb toen ik de opname maakte.

Zodra de formules kloppen ga ik even experimenteren hoe ik de beste fit krijg.
De rekentijd van deze fit is verwaarloosbaar. Het berekenen van de plaatjes was minder dan 1 seconde.

[Struikrover]

Tof project! Ik heb vorig jaar iets vergelijkbaars gedaan en ik kwam toch al een heel eind met leuke 3D effecten die zich door de boom heen verplaatsen.

Mijn eigen aanpak was echter volledig omgekeerd t.o.v. wat jij hier doet. Ik berekende eerst waar elk lichtje in theorie geplaatst moest worden, wanneer ik de streng gelijkmatig om de boom heen zou wikkelen, van onder naar boven. Ik berekende vervolgens per hoek van 90 graden, welke LED daar moest komen te liggen in de boom, en heb alleen die specifieke LEDs aan gezet.

Vervolgens heb ik de streng LEDs als een "corkscrew pattern" in de boom gehangen, zorgend dat de LEDs netjes boven elkaar lagen en de afstand ongeveer gelijk was.
Nog een beetje tunen, en klaar.

De python code die ik schreef had vervolgens een aantal functies om in 3D ruimte een lichtbron te definieren en laten animeren, en dan per LED de RGB intensiteit te definieren. Dat kun je met een puntbron doen, of met een 2D rotating plane, of wat je wilt. Je gebruikt het principe van een bounding box en berekent per "frame" voor elke LED wat de nieuwe kleur moet zijn.

Toegegeven, ik had maar 100 lampjes, dus voor jou zou het een stuk moeilijker worden mogelijk.

[edit] Ik zie dat je in je TS ook voorstelt om code te delen. Ik heb mijn code hevig gebruik laten maken van numpy en matplotlib voor diverse circulaire colormaps. Kan de code een dezer dagen wel hier posten

Voorbeeldje hoe het er uit zag:

[Voor 4% gewijzigd door Struikrover op 22-11-2022 19:57]

[Struikrover]

Overigens, als je nog een fijne library voor 3D plots zoekt, dan raak ik Plotly aan.

Hierbij een werkende code snippet waarbij je ziet hoe makkelijk plotly 3D plots zijn:
https://plotly.com/python/3d-scatter-plots/

[Batino]

Klopt het dat de kruispunten niet goed worden gevonden en dat dit de bug is die je omschrijft? Doordat de groene lijnen spiegelen in de oorsprong lijkt het alsof het goed gaat. Heb je evt. de Python code met database van de lampjes ergens beschikbaar? Misschien kan ik er een deze dagen er eens naar kijken, ik moet eerlijk zeggen dat ik het overzicht op het moment een beetje mis.

[Sgrovert]

Ik zal komende dagen eens kijken of ik de code ergens kan publiceren. Github lijkt een optie te zijn, maar misschien weten jullie nog een betere plek.

[Sgrovert]

Wegens persoonlijke omstandigheden is er even wat minder gebeurd de laatste weken.

Vandaag heb ik de classes iets betere namen gegeven en een upload op github gedaan :
https://github.com/Lahaije/PixelTree

De code is nog behoorlijk experimenteel om te testen of de concepten werken. Naamgeving van classes en variabelen kopt niet altijd omdat functionaliteit veranderd is t.o.v. het eerst idee. Dit pas ik meestal aan zodra een stuk code werkt en definitief word.

Het project in github bestaat uit 2 delen.
Folder src bevat de code.
Folder snap bevat de image data. Na het maken van de afbeeldingen in de data geclusterd en het resultaat opgeslagen in data.txt . De snap folder bevat genoeg data om de rest van de code te kunnen draaien.
Van de afbeeldingen heb ik ter referentie alleen het example geupload.

Batino schreef op vrijdag 25 november 2022 @ 12:16:
Klopt het dat de kruispunten niet goed worden gevonden en dat dit de bug is die je omschrijft?

Als het goed is is het plaatje te reproduceren door file plot.py uit te voeren.


De workflow van de verschillende scripts is momenteel :

1. Sluit de hardware aan. Voor mij is dat een esp32 via usb en de neopixels op pin 5 van de esp32
2. Zet de main.py file op de esp32.
3. Run snap_pixels vanuit verschillende richtingen. Deze slaat een serie afbeeldingen op in een snap folder.
4. Run calc_pixels. Deze clustered en maakt de data.txt file aan in elk van de snap folders
5. Run map_to_3d.py . Deze is nog niet klaar, maar output momenteel een 3d Plotly plot met berekende led posities.

[Voor 5% gewijzigd door Sgrovert op 03-12-2022 13:28]