Automatisch 3d model van lampjes in kerstboom maken

[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.

2022 Uitbreiding naar 1200 pixels. Wel veel storing gehad doordat alle pixels op 1 signaal lijn zaten

2023 Nieuwe piek en 6 ronde witte bollen. Pixels zijn opgedeelt in 8 secties van 150 / 200 pixels elk.

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.

[ Voor 5% gewijzigd door Sgrovert op 18-11-2024 23:17 . Reden: Plaatjes update 2022/2023 ]

[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 ]

[Sgrovert]

De bug met de spiegelende punten heb ik inmiddels ook opgelost.
Bij het processen van de leds, had in leds aan de linkerkant van de afbeelding een negatieve hoek gegeven. Bij het plotten van de afbeeldingen had ik counterclockwise als positieve hoek genomen.
Deze 2 definities zijn tegengesteld. Een negatieve hoek aan de linkerkant van de afbeelding komt overeen met een clockwise gedefinieerde hoek.

In de laatste iterate ben ik overgegaan op bolcoördinaten. Hierbij heb ik de definitie van Wikipedia overgenomen. Een Clockwise angle in XY is hier als positief gedefinieerd.

Met de huidige software en test data kan ik van ongeveer 50% van de leds een redelijk accurate positie vinden. Afgelopen weekend heb ik de eerste 250 leds in de boom gehangen. Deze week is het tijd voor de hardware en ga ik extra leds bijmaken. De leds waren op en de onderste 2,5 meter van de boom is nog niet verlicht.

Hopelijk kan ik volgend weekend een dataset van een echte boom maken.

[Sgrovert]

Hoog tijd voor een update.

Het mappen van de pixels is een paar weken geleden op pauze gezet. De testdata die ik gemaakt had gebruikte geen ronde boom. De aanname dat de boom rond was bleek dusdanig sterk dat de test data net niet lekker op de volautomaat wilde mappen. Indien handmatig de volgorde van de camera punten rondom de boom ingegeven werd konden de hoeken wel automatisch bepaald worden. Ook lukt het km de X, Y positie te vinden. De Z (hoogte) ben ik nog niet aan begonnen, maar is waarschijnlijk vrij makkelijk te vinden. De afstand van de camera en hoek met Z zijn immers bekend.

Om verder te komen had ik een echte boom nodig. Afgelopen weken is de boom neergezet.
De volgende sfeerbeelden kan ik jullie niet onthouden

update





Omdat de boom in de voortuin staat wil ik hem niet aan de laptop hangen voor sturing.
Afgelopen weken ben ik druk geweest om de boom van wifi te voorzien.
Dit was toch ook wel weer een flinke klus. Mijn eerste test was op Esp8266. Op deze heb ik micropython gezet en een eerste versie van de software gemaakt. Dit was mijn eerste ervaring met micropython, en micropython is niet hetzelfde voor alle devices . Afhankelijk van de hardware zijn modules wel of niet aanwezig. Het heeft best even tijd gekost voor ik hier achter was.
Uiteindelijk is het gelukt om een webserver op de esp8266 aan de praat te krijgen en gelijktijdig ook de boom te sturen. De esp draait een vast programma en via de webserver is het programma en parameters als kleur en snelheid aan te passen.
Vervolgens heb ik een uitbreiding gemaakt om volledige frames naar de boom te pushen. Een frame bevat rgb data voor alle pixels in de boom. Voor 600 pixels is een frame 600 x 3 = 1800 byte groot.
Op de esp8266 is initieel een implementatie met json frames gemaakt.
Deze werkte, maar ik haalde een framer are van slechts 3 fps.
Gelukkig zat in de electronica doos ook nog een echte esp32. 2 avonden later was code overgezet en geupgeade met een buffer. Binnen 1 request kunnen nu meerdere frames naar de boom geupload worden.
De huidige implementatie haalt 7/8 fps.
Dit jaar zal dit het maximaal haalbare zijn. Er zitten 600 pixels in de boom en het schrijven van 1 frame naar de pixels kost 120 ms.

Ik hoop tussen kerst en Nieuwjaar nog wat tijd te vinden om de mapping af te maken.
Ik moet de mapping code uitbreiden om meer dan 256 pixels te mappen en vervolgens de boom inmeten.
Hopelijk is de resolutie van de Webcam goed genoeg. De boom is 7 meter hoog en zal wel in zijn geheel op de foto moeten passen.

[Peter0903]

Leuk!

Ik volg Stand-up Maths ook en ben van plan om volgend jaar een beetje te experimenteren met dit leuke project.
Mooi om het zo dan ook mee te krijgen stap voor stap, precies de informatie die ik nodig heb om zelf verder te komen in de wereld van programmeren en elektronica!
In ieder geval maak je naast jezelf ook mij blij met dit leuke topic

[Terrz]

Gaaf project hoor, je hebt al veel gedaan en leuk dat je het proces met ons deelt!

[vonkkie]

heb je wel eens naar xlights gekeken daar kan je sinmple een boom maken met de hoeveelheid pixels en in welke lijnen
of als je wil ook van de draaiende cirkels zelf compleet zelf een boom maken met waar je pixels zitten en dan allerlei effecten er op mappen

[vonkkie]

https://xlights.org/

[Sgrovert]

Het is weer even geleden, maar hier nog een kortte update.

Afgelopen jaar is het helaas niet gelukt om de mapping helemaal werkend te krijgen. Begin december was ik een heel eind, maar toen kwam het kerst seizoen eraan. Het aantal pixels in de boom is flink uitgebreid en daarvoor was er zowel aan software als aan hardwarekant een update nodig.
In de boom hingen 2 strings met pixels. Een string had 250 pixels, andere 350 pixels.
De voeding die ik had (5V 6A) was dit jaar te klein. Deze is geupgrade naar een Meanwell RS-150-5 (5V 26A).
Voor de kabelboom heb ik een apparte voedings pigtail gemaakt. Deze word met 2 een dikke 2 aderige kabel gevoed en splits in de boom in een stuk of 6 apparte voedings kabels. De stukken in de boom zijn 1,5 m waarmee er een redelijk bereik is naar de buitinkant waar de leds zitten. De strings werden dit jaar gevoed aan het begin van de string en elke 100 leds bijgevoed. Dit werkt vrij goed, al blijf je af en toe een storing zien.

In december ben ik vooral bezig geweest met de sturing op de esp32. Op de esp32 staat micropython en is besturing via een webinterface mogelijk. Dit jaar was via een webform een aantal programma's te kiezen. Naast het programma, waren de snelheid en set van kleuren te vrij te combineren, waardoor er toch een aantal verschillende effecten gemaakt konden worden. Het heeft vrij veel tijd gekost om uit te zoeken hoe dit stabiel werkend te krijgen was.
Naast de vaste programma's is er ook een interface om complete frames naar de boom te sturen. Een frame is een json waarbij voor elke pixel in de boom een rgb waarde gestuurd word. In een enkele request kunnen meerder frames tegelijk naar de eps32 geupload worden, waarbij deze de speed waarde gebruikt om de frames op de juiste manier af te spelen. Met een buffer van ongeveer 10 frames werkte dit vrij prima.

Wel ben ik tegen de limiet van de build in neopixel library aangelopen. De 2 pixel runs had ik dit jaar aan pin 4 en 5 hangen. Ik heb helaas geen mogelijkheid gevonden waarmee de neopixel library data naar beide runs tegelijk kan sturen. Hierdoor moet voor elk frame 600 pixels sequentieel geschreven worden wat veel tijd kost. Tijdens het schrijven van een frame is de webinterface niet bereikbaar. Dit maakt hoge framerates lastig.
Komend jaar wil ik kijken om zelf een driver te maken, welke wel verschillende runs parrellel kan schrijven. Voor komend jaar wil ik 10 runs met 100 pixels maken. Wel moet ik nog even checken of er voldoende data pinnen op de esp32 zitten.

Ik hoop dit jaar nog een paar updates te kunnen vermelden in dit topic. Voor zowel software als bekabeling heb ik nog wat flinke upgrades nodig.

[Sgrovert]

vonkkie schreef op dinsdag 27 december 2022 @ 14:37:
https://xlights.org/

Als ik het goed lees is xlights een sequencer. Ik zal zelf dus de mapping van de pixels moeten maken, waarna ik het model met posities in xlights in kan laden. Vervolgens zou xlights adhv. het model een show af kunnen spelen.
Ik hou hem even in gedachten. Afspelen van animaties is iets waar ik nog niks mee gedaan heb. Een kant en klaar pakket zou hiervoor wel erg fijn zijn.

[vonkkie]

Op de esp32 kan je dan wled zetten wat weer door xlight kan worden aangestuurd

[vonkkie]

YouTube: xLights Mega Tree Winter Wonderland

[Sgrovert]

Het is tijd om het topic weer onder het stof vandaan te trekken voor een Update. Met nog 6 weken voor de boom weer staat is het tijd om weer een stukje verder te komen.
Afgelopen jaar heb ik af en toe wat stapjes in de dit project gemaakt. In december ben ik voornamelijk bezig geweest om op een esp32 met Micropython de boom aan te sturen. De esp32 kon "frames" ontvangen en vervolgens meerdere frames achter elkaar afspelen. Op mijn laptop werden de animaties berekend en verstuurd.
Helaas heb ik moeten concluderen dat de framerate op Micropython te laag is om een boom met 1000+ pixels aan te sturen. Een paar maanden geleden ben ik begonnen met wled en deze lukt het wel om meer dan 1000 pixels aan te sturen. wled heeft een udp mode, en dit jaar wil ik proberen of ik met deze mode data kan aansturen.

In januari, voordat de boom afgebroken werd, heb ik een flink aantal foto series van de boom gemaakt. Vorig jaar had ik bij het ontwikkelen het probleem dat ik geen echte boom data had, en een paar aannames moest maken. Met echte data, kan ik mijn software nu valideren en een veel beter gevoel krijgen bij wat werkt, en wat niet.
Omdat de boom meer dan 1000 pixels krijgt, ben ik met foto series van 12 foto's gaan werken. Dit werkt tot een maximum van 4096 pixels. Helaas bleek het clustering-algoritme van vorig jaar te langzaam om de grotere series in een normale tijd te kunnen berekenen.
De foto series zijn met de webcam van mijn laptop gemaakt. Deze heeft een resolutie van 640 x 480. Dit is niet heel hoog, maar op het oog is dit voldoende om afzonderlijke leds te vinden en met minder pixels blijft de rekentijd ook korter.

Afgelopen maanden ben ik dus bezig geweest om te testen met wled en heb ik verbeteringen aan het led detectie algoritme gemaakt. De led clustering is sneller als deze minder pixels hoeft door te rekenen. De truc is om pixels die waarschijnlijk geen led zijn, te filteren voordat er geclusterd gaat worden. Omdat clusteren vooral werkt om pixels te groeperen en te zoeken welke led waar zit, kan het gebruikte filter grover werken. Voor het filter is het vooral van belang dat er geen pixels die wel een led zijn gefilterd worden.
Even terug naar de afbeelding van vorig jaar

De oranje en groene lijn zijn intensiteiten van pixels die waarschijnlijk een led vertegenwoordigen. De blauwe lijn is een pixel waar geen led is. Het verschil tussen de lijnen is dat lijnen die leds vertegenwoordigen hoge en lage waarden hebben, terwijl achtergrond pixels altijd een lage waarde blijven houden.
Het pixel filter maakt gebruik van deze eigenschap. De variance is een statische waarde die aangeeft hoe constant een lijn is. Pixels met een hoge variance in de image series zijn waarschijnlijk een led, pixels met een lage variance zijn background.

Met het variance filter is de clustering en classificering van de leds opeens wel te doen. De nieuwe algoritmes zijn binnen 10 sec klaar. Binnen een serie wordt ongeveer 1/4 tot 1/3 van alle leds gevonden. In theorie zou 50% van de leds zichtbaar zijn (de helft zit aan de andere kant van de boom), maar praktisch is dit minder, omdat de leds soms ook achter een tak vallen, of de led precies de verkeerde kant op schijnt.
Hieronder zijn de resultaten van 2 metingen



De afbeelding zijn klikbaar om de led detectie te kunnen zien. Om de text leesbaar te kunnen maken heb ik de afbeelding voor het plotten 5x vergroot. Origineel zijn deze ongeveer 240 x 450 pixels. Dit is vooral goed zichtbaar aan de bovenkant van de boom. Het up-samplen is alleen voor het plotten van de afbeelding. Alle berekeningen zijn gedaan om de echte data.

In het midden van de boom is een bijna verticale blauwe lijn. Dit is de smallest mean sqaure lijn dit door de data past. Op het oog staat deze vrij netjes in het midden van de boom. Dit is precies waar je hem verwacht en deze lijn kan gebruikt worden als centrum van de boom.

In de afbeelding zijn gevonden leds omcirkelt en staat hun ID erbij. De leds zitten oplopend in een ketting. Deze begint bij 0 en loopt door tot 599. De ketting zit als een spiraal om de boom been. Hierdoor is bekend dat led 1 naast led 2 zit, led 2 naast led 3 etc.
De gevonden leds zijn in 3 kleuren weergegeven. Groene leds zijn waarschijnlijk correct. Paarse punten zijn bijna zeker fout. Rode leds zijn waarschijnlijk fout. Een led kan alleen rood worden als er ergens een groene led met hetzelfde nummer gevonden is.
In het geel zijn ketens van leds getekend. Een keten is een string van oplopende led ID die allemaal gevonden zijn. Een keten heeft een cut off van 5 missende leds, voordat deze beëindigd wordt.
Ketens worden betrouwbaar vanaf 3 leds in een keten. Veel van de lange rechte lijnen die zichtbaar zijn worden veroorzaakt doordat de keten slechts 2 leds heeft. Op de ketens zit namelijk een filter, welke leds zoekt die in lijn met de rest van de keten zijn. Als leds meer dan 5x de gemiddelde afstand ver liggen, worden deze uit de keten verwijderd. Dit algoritme werkt op elke vergroting, maar eigenlijk wel pas goed vanaf minimaal 4 leds in een keten.

Met de nieuwe data kunnen nu een flink aantal leds met grote betrouwbaarheid gevonden worden. Leds dit in een keten van 4 of langer zitten, zijn bijna allemaal wel correct. Kijkend naar de afbeeldingen hierboven hebben beide series veel leds met een id tussen de 55 en 80 gevonden. Met ook een vrij betrouwbare nullijn ga ik nu proberen of ik kan vinden welke hoek beide camera's met elkaar maken.

[Sgrovert]

Ik ben aan het kijken of het mogelijk is om de bepaling van de camera posities in een matrix berekening te stoppen. Kijkend naar de afbeeldingen hierboven, hebben de 2 afbeeldingen veel leds in beide afbeeldingen.
Definities :
Lx = (Led id = x)
C1 = Camera 1 (linker afbeelding)
C2 = Camera 2 (rechter afbeelding)

Om een 3D model te maken zullen de camera positief bepaald moeten worden.
C1 = (C1x, C1y, C1z)
C2 = (C2x, C2y, C2z)
Lx = (x, y, z)

Binnen beide afbeelding komend de x, y van een led overeen met een hoek tussen de normaal van de censor. Deze hoeken definieer ik als
Lc1 = (i, j)
en
Lc2 = (i, j)
In beide afbeeldingen geld dan voor de blauwe lijn () centrum boom I = m * j + c en zijn m en c bekend.

Verder kunnen de volgende definities gemaakt worden:
- het centrum van de boom staat op (0, 0, z)
- C1 Staat op coördinaat (1, 0, 0)
- (leds in de bomen mogen een negatieve z krijgen)

elke led in een afbeelding is een vector V,
Vector(C -> L) = (Cx - Lx, Cy - Ly, Cz - Lz)

Binnen een afbeelding maken 2 vectoren een bekende hoek met elkaar
V(C1 -> L1) -> (C1 -> L2) = (L1(i), L1(j)) - (L2(i) , L2(j))

Omdat elke led in 2 afbeelding zit, zijn er voor elke led 4 dingen bekend. 2x I en 2x J. elke led heeft een (x, y, z) coördinaat die onbekend is. Wiskundig gezien denk ik dat er voor elke led dus 4 vergelijkingen met 3 onbekenden te maken moeten zijn. Indien deze vergelijkingen in een matrix berekening gestopt kunnen worden zouden de posities van de leds en de camera's te vinden moeten zijn.

Mijn wiskunde is helaas erg ver weggezakt. Kan iemand helpen met het opstellen van de vergelijkingen en het maken van een matrix?
Met een least squares fit zou de positie van C2 en de leds dan te bepalen moeten zijn.

[TorxWorx]

Gaaf project! Ik zie dit topic voor nu pas voor het eerst moet ik bekennen. De vraag over positiebepaling heeft mij wel aan het denken gezet. Aangezien definities en (on)bekenden de kern zijn van dit soort lineaire algebra gerelateerde problemen heb ik eerst nog wat vragen:

Sgrovert schreef op zaterdag 21 oktober 2023 @ 18:20:

Om een 3D model te maken zullen de camera positief bepaald moeten worden.
C1 = (C1x, C1y, C1z)
C2 = (C2x, C2y, C2z)
Lx = (x, y, z)

Verder kunnen de volgende definities gemaakt worden:
- het centrum van de boom staat op (0, 0, z)
- C1 Staat op coördinaat (1, 0, 0)
- (leds in de bomen mogen een negatieve z krijgen)

Wat weet je in de huidige situatie nog meer over C2? Is het doel om een foto welke gemaakt is vanuit een willekeurige positie in te laden en vervolgens achteraf de positie te bepalen, zo ja op hoeveel foto's wil je dit toepassen? Neem je elke foto orthogonaal op de boom?(staat het midden van het beeld haaks staat op z/2?) Is elke foto vanaf dezelfde afstand genomen?

Sgrovert schreef op zaterdag 21 oktober 2023 @ 18:20:

Binnen beide afbeelding komend de x, y van een led overeen met een hoek tussen de normaal van de censor. Deze hoeken definieer ik als
Lc1 = (i, j)
en
Lc2 = (i, j)
In beide afbeeldingen geld dan voor de blauwe lijn () centrum boom I = m * j + c en zijn m en c bekend.

Kun je deze definitie nog iets verduidelijken? Is de set hoeken (i, j) uitgedrukt ten opzichte van de foto of ten opzichte van het globale assenstelsel. Mij is het niet duidelijk waarom je een 3D lijn (centrum boom) wil uitdrukken in een 2D representatie.



Als ik de gebruikte definities volg dan zie ik het zoals hierboven weergegeven. Je uiteindelijke doel is om alles in het globale referentie frame (N frame) uit te drukken. Elke camera positie geeft de positie vanuit een een eigen referentie frame weer. Bij C1 is dit eenvoudig, dit frame (het B frame) heeft dezelfde richtingen als het N frame. Ik ga er even van uit dat je de camera enkel roteert rond de z-as, als je rond de boom beweegt creëer je dus een nieuw referentie frame: Het camera-fixed frame F. Elke foto die je neemt is dus een projectie in het z' / y' vlak en dus niet in x en y.

Met het bewegen rond de boom introduceer je nog een probleem: Een onbekende hoek thèta, ervan uitgaande dat de afstand tot de boom gelijk blijft.

Sgrovert schreef op zaterdag 21 oktober 2023 @ 18:20:

elke led in een afbeelding is een vector V,
Vector(C -> L) = (Cx - Lx, Cy - Ly, Cz - Lz)

Hierdoor kun je dit volgens mij niet meer stellen. De vectoren die je hiermee probeert te verkrijgen hebben een verschillend referentie frame. ^Nr_L/C =/= ^Fr_L/C
standaardnotatie: linksboven staat het frame waarin een vector uitgedrukt is, rechtsonder: bijv. punt L ten opzichte van punt C.

De oplossing hiervoor is meestal een rotatiematrix, hiermee kun je vectoren omschrijven naar verschillende frames. In dit geval is er enkel een rotatie rond de z-as dus:


Verder kunnen we gebruik maken van een handige eigenschap van een rotatiematrix: door de getransponeerde te nemen kun je van F naar N:


Hiermee heb je nog niet direct een manier om het hele positie probleem in een matrix vorm te krijgen, toch is het als eerste stap wel noodzakelijk dat de definities kloppen alvorens verder te gaan.

[Sgrovert]

@TorxWorx,
Thx voor je input. Jouw uitwerking is inderdaad de richting die ik zelf ook al dacht. Helaas heb ik 20 jaar geleden voor het laatst iets met linear Algebra gedaan en is de kennis een beetje ver weggezakt. Ik vind het daarom vrij lastig om het precies goed op te schrijven.
[quote]
Wat weet je in de huidige situatie nog meer over C2?

uit de data kan ik halen of deze Clockwise of Counterclockwise om de boom geroteerd is.
In dit geval stonden C1 en C2 op dezelfde hoogte, maar vanaf de huiskant lukt dat niet. Daar kan ik de Camera de camera op de begane grond en eerste verdieping zetten en door het raam een set images maken. Het glas heeft minimaal invloed op de led detectie.

Is het doel om een foto welke gemaakt is vanuit een willekeurige positie in te laden en vervolgens achteraf de positie te bepalen

Correct. Als het enigzinds te doen is zou dat het ultieme doel zijn.
Eventueel kan het requirement zijn om eerst een serie foto's rondon op een vastte hoogte te nemen, en vervolgens later als het nodig is de foto's van bovenaf toe te voegen in een ander algoritme.
Het aantal posities is niet bepaald. Maar door de grootte van de boom, het huis en geparkeerde auto's is het niet mogelijk om met een vast aantal evenredig veerdeeld aantal posities op dezelfde afstand een afbeelding te maken.

zo ja op hoeveel foto's wil je dit toepassen?

Ik wilde beginnen met 2. Als uit 2 foto's de camera positie te bepalen is, kun je vervolgens rondom de boom dit algoritme op elke set van 2 posities toepassen. Dit zou terug te zetten moeten zijn naar alle positief relatief t.o.v. C1. Nadat de posities bepaald zijn kan vervolgens van alle leds de informatie uit alle beelden gebruikt worden om tot een fit te komen.

Neem je elke foto orthogonaal op de boom?

Nee. De camera staat op ongeveer 1,5 meter hoog. De boom is 7 meter. De camera moet schuin omhoog gericht worden om de hele boom in beeld te krijgen. Ik probeer de boom in het midden van het beeld te zetten, maar dit lukt niet 100%

Is elke foto vanaf dezelfde afstand genomen?

Nee

Kun je deze definitie nog iets verduidelijken? Is de set hoeken (i, j) uitgedrukt ten opzichte van de foto of ten opzichte van het globale assenstelsel. Mij is het niet duidelijk waarom je een 3D lijn (centrum boom) wil uitdrukken in een 2D representatie.

Ik leen even een afbeelding om het proberen te verduidelijken

Voor elke afbeelding staat de camera in (0,0,0) op de afbeelding hierboven. Vector U is de vector van de camera naar een led. Met de X, Y zoals @TorxWorx in de schets gedefinieerd heeft komt I,J overeen met hoek Gamma en Bèta in de afbeelding hierboven. Met het centrum van de boom bekend (blauwe lijn), kan centrum boom op de X as geplaatst worden. Hoek Gamma is daarmee exact bepaald. Hoek Beta is momenteel alleen relatief. Ik heb geen referentie om te bepalen waar de onderkant van de boom is. Hier heb ik 2 ideeën over:
1) de lijn van de laagst zichbare led loodrecht op centrum boom bepaald Z = 0.
2) De "hoogte" van de gemiddelde of mediaan led word gebruikt om loodrecht op centrum boom een lijn te tekenen en Z = 0 te bepalen.
Ik durf even niet te zeggen welke methode het bestte resultaat gaat geven, maar hier kan ik later mee experimenteren.

Met het bewegen rond de boom introduceer je nog een probleem: Een onbekende hoek thèta, ervan uitgaande dat de afstand tot de boom gelijk blijft.

Correct. In essentie zoek ik naar een berekenen die een smallest squares fit voor theta kan maken.

Hierdoor kun je dit volgens mij niet meer stellen. De vectoren die je hiermee probeert te verkrijgen hebben een verschillend referentie frame. NrL/C =/= FrL/C

Dat klopt. Ik heb het denk ik een beetje ongelukkig opgeschreven.

De oplossing hiervoor is meestal een rotatiematrix, hiermee kun je vectoren omschrijven naar verschillende frames. In dit geval is er enkel een rotatie rond de z-as dus:

Voor de eerste oplossing zou het al heel mooi zijn als we deze kunnen gebruiken. Bij de images die ik gepost heb is deze matrix correct, omdat de camera op dezelfde hoogte blijft.

[Sgrovert]

Wat meer afbeeldingen inclusief de led data.
Theta is relatief T.O.V van de eerste afbeelding
Z is de camera hoogte geschat vanaf de grond.

Elke afbeelding heeft de ruwe led data erbij staan. De data is een dictionaty waarin de key het led_id is, en elke value een coördinaat (i, j) in de afbeelding is.

Theta = 0 Z = 1,5 m		code: {'Theta': '0', 'Z': 1.5, 'm': -0.009140904207365918, 'c': 341.2053241516312, 223: (309, 355), 320: (358, 176), 493: (128, 334), 494: (126, 327), 161: (328, 283), 461: (166, 378), 227: (308, 323), 489: (143, 355), 60: (400, 360), 319: (249, 271), 221: (310, 368), 290: (262, 401), 464: (169, 375), 425: (178, 358), 361: (220, 387), 88: (362, 262), 293: (250, 393), 56: (405, 389), 428: (169, 342), 71: (383, 292), 496: (131, 321), 157: (324, 296), 523: (116, 359), 226: (310, 330), 75: (385, 270), 549: (92, 342), 155: (334, 300), 445: (178, 308), 308: (257, 317), 152: (347, 322), 140: (360, 399), 57: (409, 379), 416: (190, 382), 466: (165, 368), 240: (278, 273), 70: (378, 299), 522: (117, 365), 225: (310, 339), 315: (244, 288), 164: (322, 267), 534: (112, 325), 354: (229, 383), 470: (158, 352), 495: (127, 322), 559: (74, 340), 64: (394, 334), 296: (250, 385), 519: (121, 373), 544: (98, 338), 242: (281, 271), 234: (295, 289), 63: (394, 344), 362: (220, 382), 62: (400, 347), 77: (379, 259), 432: (162, 325), 304: (264, 343), 219: (308, 381), 151: (351, 328), 430: (160, 331), 69: (385, 310), 58: (408, 372), 310: (251, 307), 217: (314, 394), 68: (377, 305), 548: (88, 340), 518: (125, 372), 557: (84, 335), 154: (340, 308), 48: (407, 427), 330: (245, 301), 59: (407, 365), 6: (400, 266), 266: (292, 356), 287: (271, 408), 238: (287, 275), 158: (333, 289), 360: (221, 384), 141: (362, 392), 162: (329, 272), 235: (294, 285), 73: (383, 278), 369: (214, 360), 424: (180, 367), 560: (68, 334), 78: (376, 254), 423: (183, 372), 52: (400, 406), 136: (359, 411), 143: (352, 380), 61: (402, 351), 239: (283, 274), 578: (82, 324), 313: (243, 305), 208: (331, 394), 364: (218, 376), 366: (216, 370), 573: (89, 336), 325: (248, 290), 580: (71, 329), 437: (170, 306), 243: (281, 270), 276: (277, 392), 283: (267, 406), 497: (136, 319), 486: (154, 359), 218: (307, 384), 146: (359, 361), 561: (74, 341), 306: (262, 329), 147: (356, 356), 299: (259, 370), 205: (328, 394), 434: (165, 314), 45: (400, 428), 530: (113, 323), 74: (384, 276), 415: (196, 383), 542: (106, 341), 55: (407, 391), 159: (326, 283), 236: (289, 288), 587: (61, 338), 237: (290, 278), 288: (268, 400), 459: (173, 367), 433: (167, 320), 439: (162, 301), 309: (254, 313), 165: (328, 273), 278: (276, 393), 339: (244, 312), 469: (159, 358), 128: (360, 418), 374: (205, 338), 314: (245, 299), 211: (326, 394), 435: (169, 311), 514: (135, 374), 388: (228, 278), 478: (151, 329), 527: (109, 330), 525: (114, 344), 367: (216, 362), 124: (360, 420), 35: (396, 400), 228: (306, 318), 436: (170, 310), 139: (362, 399), 488: (147, 361)}
Theta = 1/2 π Z = 1,5 m		code: {'Theta': '1/2', 'Z': 1.5, 'm': -0.007472636373063977, 'c': 396.1493186652511, 62: (427, 328), 549: (113, 389), 449: (198, 421), 365: (241, 377), 207: (354, 427), 276: (290, 457), 287: (286, 402), 355: (232, 435), 485: (164, 414), 112: (378, 482), 303: (299, 316), 362: (234, 400), 124: (385, 453), 364: (237, 384), 59: (435, 344), 561: (102, 373), 35: (429, 496), 56: (435, 361), 63: (421, 325), 291: (280, 374), 451: (182, 429), 138: (389, 379), 566: (93, 403), 488: (163, 395), 208: (354, 419), 361: (233, 409), 140: (387, 364), 210: (351, 407), 128: (386, 433), 354: (238, 433), 271: (293, 474), 353: (246, 432), 511: (139, 437), 270: (300, 472), 424: (202, 371), 366: (238, 370), 590: (73, 390), 368: (236, 354), 415: (206, 413), 205: (350, 436), 29: (422, 484), 142: (381, 352), 292: (422, 317), 206: (356, 432), 274: (286, 467), 234: (442, 468), 123: (386, 460), 290: (282, 377), 66: (411, 311), 363: (238, 392), 469: (194, 379), 357: (224, 438), 200: (345, 470), 557: (110, 377), 536: (144, 388), 313: (280, 333), 550: (110, 397), 583: (94, 393), 133: (385, 407), 45: (434, 453), 523: (139, 372), 214: (343, 380), 369: (243, 348), 493: (158, 368), 473: (177, 372), 223: (338, 330), 60: (427, 336), 548: (113, 383), 569: (95, 406), 337: (305, 374), 448: (179, 410), 372: (246, 333), 275: (281, 461), 409: (211, 443), 110: (385, 479), 300: (294, 337), 319: (290, 332), 299: (287, 341), 576: (108, 389), 585: (89, 393), 221: (339, 338), 41: (442, 469), 588: (79, 391), 423: (202, 378), 293: (273, 358), 70: (404, 307), 432: (239, 390), 453: (183, 425), 559: (101, 369), 552: (111, 402), 514: (138, 423), 470: (182, 376), 132: (384, 411), 272: (282, 472), 225: (341, 324), 72: (405, 313), 226: (341, 320), 67: (407, 314), 456: (183, 426), 65: (412, 321), 204: (317, 440), 593: (60, 392), 494: (158, 365), 359: (230, 424), 596: (199, 383), 227: (341, 316), 520: (125, 394), 381: (246, 354), 416: (202, 405), 203: (348, 454), 491: (165, 377), 489: (163, 386), 529: (143, 366), 376: (235, 344), 519: (135, 390), 594: (54, 392), 568: (90, 405), 178: (353, 410), 535: (139, 384), 378: (235, 348), 462: (174, 428), 360: (234, 414), 58: (437, 351), 57: (439, 357), 562: (100, 379), 333: (281, 413), 518: (137, 397), 530: (146, 368), 126: (385, 442), 281: (286, 433), 68: (404, 305), 461: (172, 423), 521: (132, 390), 134: (386, 395), 49: (443, 431), 335: (275, 422), 571: (104, 408), 108: (390, 474), 542: (128, 391), 534: (142, 381), 460: (178, 430), 144: (332, 376), 464: (177, 416), 263: (310, 463), 145: (388, 343), 146: (388, 335), 199: (341, 462), 492: (163, 371), 564: (91, 392), 285: (260, 418), 279: (290, 443), 139: (389, 373), 212: (391, 473), 288: (263, 417), 248: (315, 390), 43: (440, 465), 405: (206, 454), 525: (141, 370), 295: (266, 357), 457: (188, 426), 439: (198, 366), 490: (183, 427), 347: (282, 401), 117: (390, 472), 228: (338, 318), 42: (443, 467), 391: (256, 385), 289: (285, 387), 218: (333, 354), 441: (197, 374), 408: (209, 440), 398: (210, 412), 486: (168, 408), 309: (322, 347), 39: (442, 478), 78: (403, 320), 425: (204, 365), 155: (366, 314), 506: (138, 421), 154: (370, 319), 224: (301, 392), 512: (125, 424), 260: (315, 447), 356: (262, 373), 236: (218, 363), 283: (284, 369)}
Theta = 3/4 π Z = 4,0 m		code: {'Theta': '3/4', 'Z': 4.0, 'm': -0.023981243410072337, 'c': 323.0046969474496, 572: (92, 375), 559: (121, 279), 504: (215, 391), 417: (421, 224), 414: (436, 277), 569: (99, 319), 488: (299, 276), 552: (137, 336), 451: (326, 410), 485: (305, 317), 550: (140, 316), 542: (181, 317), 543: (164, 325), 409: (453, 364), 567: (78, 327), 564: (99, 279), 566: (96, 310), 456: (366, 366), 568: (82, 322), 420: (406, 205), 511: (238, 343), 471: (313, 260), 376: (416, 242), 562: (115, 281), 442: (329, 368), 540: (185, 313), 484: (299, 344), 458: (359, 341), 513: (236, 325), 407: (444, 398), 506: (206, 386), 427: (359, 234), 487: (305, 290), 454: (337, 386), 469: (333, 255), 473: (315, 265), 463: (357, 296), 521: (232, 239), 486: (311, 307), 450: (342, 410), 505: (199, 397), 575: (113, 355), 405: (435, 414), 460: (367, 311), 424: (396, 215), 449: (354, 408), 403: (446, 426), 590: (25, 318), 475: (322, 296), 516: (249, 284), 411: (461, 329), 514: (252, 305), 563: (110, 282), 415: (445, 250), 366: (477, 204), 413: (456, 291), 588: (42, 318), 501: (241, 373), 462: (367, 293), 520: (226, 224), 586: (66, 336), 410: (444, 351), 401: (449, 423), 406: (423, 413), 438: (330, 332), 545: (160, 327), 396: (447, 410), 509: (240, 371), 441: (314, 352), 585: (77, 317), 466: (350, 265), 431: (339, 253), 571: (109, 355), 518: (245, 251), 525: (223, 267), 524: (225, 261), 426: (380, 234), 455: (356, 381), 581: (105, 319), 574: (113, 377), 517: (251, 264), 589: (24, 338), 367: (468, 211), 372: (452, 190), 453: (329, 397), 399: (451, 413), 526: (219, 273), 457: (368, 350), 493: (254, 283), 577: (118, 353), 467: (353, 270), 546: (156, 328), 432: (339, 243), 503: (223, 388), 398: (452, 417), 557: (131, 305), 515: (252, 294), 433: (343, 262), 541: (189, 329), 523: (230, 247), 443: (332, 384), 468: (345, 272), 452: (332, 425), 378: (412, 259), 429: (353, 246), 538: (210, 330), 483: (293, 352), 408: (434, 375), 444: (331, 395), 553: (146, 349), 508: (236, 371), 576: (109, 352), 430: (337, 239), 578: (117, 339), 573: (114, 365), 570: (108, 335), 402: (449, 426), 565: (104, 297), 368: (454, 200), 418: (406, 213), 412: (460, 309), 561: (117, 283), 422: (409, 215), 476: (315, 308), 519: (241, 235), 392: (421, 407), 544: (162, 317), 527: (216, 278), 440: (311, 361), 491: (283, 279), 551: (133, 339), 478: (293, 333), 446: (350, 402), 529: (211, 295), 369: (462, 193), 395: (446, 412), 522: (232, 242), 481: (286, 343), 547: (128, 375), 336: (116, 283), 459: (365, 319), 558: (125, 285), 496: (254, 311)}
Theta = 3/4 π Z = 0,75 m		code: {'Theta': '3/4', 'Z': 0.75, 'm': 0.025634659373586305, 'c': 299.7503953147159, 102: (410, 427), 207: (339, 241), 465: (97, 290), 350: (190, 330), 276: (228, 304), 333: (238, 381), 31: (466, 380), 460: (79, 307), 200: (312, 302), 131: (391, 199), 120: (397, 292), 415: (121, 277), 269: (247, 358), 289: (250, 211), 122: (394, 265), 456: (92, 338), 29: (457, 386), 517: (47, 282), 402: (131, 374), 352: (179, 310), 123: (385, 250), 357: (140, 278), 411: (129, 317), 125: (391, 242), 113: (380, 380), 192: (339, 385), 28: (463, 398), 278: (233, 285), 106: (402, 422), 203: (323, 277), 115: (387, 355), 210: (340, 219), 117: (395, 331), 450: (99, 365), 354: (165, 291), 212: (335, 208), 110: (389, 402), 462: (76, 296), 355: (153, 286), 399: (169, 370), 108: (401, 408), 412: (132, 306), 277: (221, 290), 107: (405, 409), 274: (218, 320), 397: (186, 373), 409: (118, 337), 285: (228, 223), 287: (246, 209), 464: (88, 290), 488: (83, 287), 185: (350, 404), 208: (343, 243), 485: (72, 311), 291: (248, 195), 401: (141, 374), 268: (247, 374), 467: (105, 283), 133: (390, 188), 423: (144, 248), 121: (397, 274), 486: (81, 305), 206: (342, 252), 196: (318, 346), 118: (398, 318), 119: (397, 308), 341: (195, 401), 191: (334, 391), 344: (192, 377), 405: (103, 365), 104: (405, 427), 343: (200, 383), 298: (265, 206), 105: (407, 412), 360: (167, 266), 368: (200, 233), 124: (385, 233), 114: (386, 369), 130: (388, 198), 26: (467, 419), 458: (83, 324), 361: (168, 258), 369: (211, 228), 457: (97, 330), 281: (233, 249), 396: (189, 370), 538: (52, 318), 193: (334, 373), 273: (215, 341), 265: (264, 397), 463: (78, 299), 400: (150, 376), 294: (237, 198), 270: (239, 351), 363: (185, 253), 515: (40, 298), 116: (390, 342), 103: (398, 418), 67: (341, 242), 459: (90, 312), 422: (136, 249), 389: (230, 357), 413: (134, 295), 264: (268, 405), 508: (37, 340), 407: (111, 356), 504: (166, 306), 481: (94, 336), 364: (187, 245), 128: (387, 212), 539: (46, 317), 209: (342, 235), 522: (56, 268), 258: (284, 394), 366: (196, 238), 542: (42, 311), 60: (463, 195), 356: (143, 283), 489: (90, 284), 476: (115, 305), 470: (120, 274), 398: (177, 373), 449: (110, 360), 299: (270, 205), 362: (175, 254), 367: (203, 242), 491: (97, 288), 424: (147, 248), 53: (468, 173), 487: (85, 295), 112: (366, 377), 266: (260, 381), 359: (157, 272), 410: (111, 313), 521: (47, 268), 335: (226, 390), 426: (155, 258), 520: (37, 261), 283: (232, 230), 421: (128, 247), 516: (41, 293), 414: (126, 287), 293: (245, 191), 540: (39, 308), 358: (149, 279), 253: (284, 391), 431: (162, 270), 466: (101, 281), 138: (402, 176), 534: (66, 320), 519: (84, 261), 490: (94, 288), 429: (145, 280), 263: (262, 393), 213: (329, 208), 451: (87, 363), 420: (129, 249), 518: (49, 274), 475: (121, 298), 425: (153, 254), 372: (222, 224), 50: (466, 168), 30: (467, 383), 447: (121, 344), 295: (236, 194), 282: (243, 240), 349: (178, 293), 255: (285, 396), 160: (323, 287), 365: (196, 249), 428: (158, 257), 438: (155, 321), 74: (82, 307), 267: (256, 371), 483: (81, 330), 215: (324, 193), 286: (240, 225), 331: (246, 367), 454: (164, 364), 190: (342, 398), 469: (112, 274), 288: (249, 216), 347: (200, 347), 334: (234, 392), 204: (331, 276)}
Theta = 3/4 π Z = 0,75 m		code: {'Theta': '3/4', 'Z': 0.75, 'm': -0.05191510978841681, 'c': 346.47442207692944, 208: (99, 245), 307: (18, 241), 54: (279, 166), 191: (85, 480), 31: (292, 464), 75: (337, 512), 58: (280, 188), 102: (198, 515), 200: (45, 341), 115: (169, 425), 110: (173, 495), 207: (89, 242), 125: (175, 246), 118: (186, 365), 123: (166, 258), 196: (57, 413), 105: (194, 496), 108: (191, 499), 210: (93, 207), 28: (282, 487), 106: (188, 517), 131: (171, 179), 122: (180, 282), 203: (65, 298), 43: (310, 248), 29: (274, 468), 120: (184, 325), 22: (296, 523), 119: (185, 351), 114: (168, 445), 42: (318, 261), 192: (93, 471), 117: (182, 386), 124: (166, 230), 46: (311, 201), 112: (149, 468), 36: (312, 372), 185: (111, 486), 258: (9, 477), 209: (98, 232), 39: (321, 321), 133: (169, 164), 41: (319, 274), 419: (197, 498), 253: (11, 465), 121: (185, 297), 104: (192, 519), 206: (97, 259), 52: (269, 153), 40: (322, 303), 61: (264, 204), 33: (304, 434), 60: (261, 188), 212: (86, 189), 59: (275, 193), 5: (272, 457), 44: (310, 220), 107: (194, 499), 113: (159, 463), 116: (174, 402), 35: (294, 395), 26: (286, 513), 56: (273, 165), 53: (277, 154), 213: (76, 190), 130: (168, 180), 245: (42, 402), 14: (278, 517), 128: (168, 199), 25: (293, 512), 17: (277, 530), 138: (184, 151), 189: (103, 468), 201: (51, 342), 126: (165, 234), 218: (75, 170), 204: (79, 296), 215: (69, 168), 95: (192, 479), 57: (283, 182), 109: (171, 511), 62: (260, 203), 94: (198, 470), 50: (276, 144), 55: (281, 175), 190: (98, 488), 103: (182, 503), 198: (55, 364), 51: (280, 157), 142: (128, 144), 38: (320, 334), 318: (3, 343), 127: (186, 222)}

[TorxWorx]

Sgrovert schreef op maandag 23 oktober 2023 @ 20:37:
@TorxWorx,
Thx voor je input. Jouw uitwerking is inderdaad de richting die ik zelf ook al dacht. Helaas heb ik 20 jaar geleden voor het laatst iets met linear Algebra gedaan en is de kennis een beetje ver weggezakt. Ik vind het daarom vrij lastig om het precies goed op te schrijven.
[quote]
Wat weet je in de huidige situatie nog meer over C2?

[...]


[...]

Correct. Als het enigzinds te doen is zou dat het ultieme doel zijn.
Eventueel kan het requirement zijn om eerst een serie foto's rondon op een vastte hoogte te nemen, en vervolgens later als het nodig is de foto's van bovenaf toe te voegen in een ander algoritme.
Het aantal posities is niet bepaald. Maar door de grootte van de boom, het huis en geparkeerde auto's is het niet mogelijk om met een vast aantal evenredig veerdeeld aantal posities op dezelfde afstand een afbeelding te maken.


[...]

Ik wilde beginnen met 2. Als uit 2 foto's de camera positie te bepalen is, kun je vervolgens rondom de boom dit algoritme op elke set van 2 posities toepassen. Dit zou terug te zetten moeten zijn naar alle positief relatief t.o.v. C1. Nadat de posities bepaald zijn kan vervolgens van alle leds de informatie uit alle beelden gebruikt worden om tot een fit te komen.


[...]

Nee. De camera staat op ongeveer 1,5 meter hoog. De boom is 7 meter. De camera moet schuin omhoog gericht worden om de hele boom in beeld te krijgen. Ik probeer de boom in het midden van het beeld te zetten, maar dit lukt niet 100%


[...]

Nee


[...]

Ik leen even een afbeelding om het proberen te verduidelijken
[Afbeelding]
Voor elke afbeelding staat de camera in (0,0,0) op de afbeelding hierboven. Vector U is de vector van de camera naar een led. Met de X, Y zoals @TorxWorx in de schets gedefinieerd heeft komt I,J overeen met hoek Gamma en Bèta in de afbeelding hierboven. Met het centrum van de boom bekend (blauwe lijn), kan centrum boom op de X as geplaatst worden. Hoek Gamma is daarmee exact bepaald. Hoek Beta is momenteel alleen relatief. Ik heb geen referentie om te bepalen waar de onderkant van de boom is. Hier heb ik 2 ideeën over:
1) de lijn van de laagst zichbare led loodrecht op centrum boom bepaald Z = 0.
2) De "hoogte" van de gemiddelde of mediaan led word gebruikt om loodrecht op centrum boom een lijn te tekenen en Z = 0 te bepalen.
Ik durf even niet te zeggen welke methode het bestte resultaat gaat geven, maar hier kan ik later mee experimenteren.


[...]

Correct. In essentie zoek ik naar een berekenen die een smallest squares fit voor theta kan maken.


[...]

Dat klopt. Ik heb het denk ik een beetje ongelukkig opgeschreven.


[...]


Voor de eerste oplossing zou het al heel mooi zijn als we deze kunnen gebruiken. Bij de images die ik gepost heb is deze matrix correct, omdat de camera op dezelfde hoogte blijft.

Deze antwoorden maken het al duidelijker, het is idd lastig om dit soort vraagstukken via tekst over te brengen. Om die reden heb ik ff snel wat plaatjes gemaakt in cad.





Hierbij geeft de triad (pijlen) de volgende richtingen weer: rood=X, groen=Y, blauw=Z.

Sgrovert schreef op maandag 23 oktober 2023 @ 20:37:
@TorxWorx,

Voor de eerste oplossing zou het al heel mooi zijn als we deze kunnen gebruiken. Bij de images die ik gepost heb is deze matrix correct, omdat de camera op dezelfde hoogte blijft.

Doordat de camera een hoek phi maakt met de grond wordt het probleem nog iets lastiger. Ik was eerst uitgegaan van een camera die een beeld maakt recht op de boom (dus een semi 2D situatie). Als de camera omhoog wijst is de hoek phi ook afhankelijk van de afstand tot de boom (ervan uitgaande dat je het midden van het camera beeld uitlijnt met z/2. Om vectoren vanuit het camera fixed frame uit te drukken heb je dus een dubbele rotatiematrix:

Het F frame is nog steeds het camera fixed frame. De rotatiematrix F^C_G beschrijft de hoek die het F frame maakt met het G frame( rotatie rond y'). De G^C_N matrix geeft de rotatie van hoek theta tov. het global reference frame, dit zijn de triads die op het grond vlak getekend zijn.

Daarbij komt dat je voor het oplossen van een triangulation probleem (driehoeks vergelijking) ook een verplaatsingsvector nodig hebt van C1 naar C2. Hieronder weergegeven als de lichtblauwe lijn.


Samengevat: De camera C2 heeft 5 DOF (vrijheidsgraden), 3 DOF voor translatie: [x, y, z]^T en 2 DOF voor rotatie: theta en phi. De kant en klare oplossing die je kunt kopen kan de state van de camera vaststellen door gebruik te maken van de accelerometer van de telefoon aangezien tweemaal integreren van de acceleraties weer afstand en rotatie geeft.

Ik denk dat ondanks dat een hoop variabelen onbekend zijn dit vraagstuk wel op te lossen is. Als ik wat meer tijd heb kan ik eens kijken of ik nog wat meer kan verduidelijken en in vector vorm kan opschrijven.

[TorxWorx]

deel 2:
De makkelijkste manier om dit probleem op te lossen zou zijn een vector opstellen van het camerabrandpunt tot het denkbeeldige image vlak, daarna deze vector normaliseren (lengte = 1). Met deze vectoren voor beide C’s zou je in theorie het snijpunt kunnen bepalen door deze te lineariseren, je weet immers dat de positie van de led in het N frame vanuit beide standpunten overeen moet komen. In vector vorm
^Nr_C1/Center + a * ^Nr_{image 1/C1} = ^Nr_C2/Center + b * ^Nr_{image 2/C2}
Deze vergelijking oplossen voor a en b zorgt ervoor dat je in theorie de exacte positie hebt van de led. Nu komt het probleem: Als er een onnauwkeurigheid zit in phi, theta of in een van de opgestelde vectoren heb je geen oplossing voor deze vergelijking, er is dan simpelweg geen snijpunt.

Om een snijpunt te bepalen kom heb je dus een numerieke methode nodig waarbij je de projectie error^2 minimaliseert. Waarschijnlijk kom je dan op een algoritme uit waarbij je moet itereren over de z’ en y’ in het image plane. Aangezien dit in twee richtingen werkt zal je op iets niet-lineairs uitkomen dus volgens mij wordt het dan de Gauss-Newton methode.

Nu ik er iets langer over na heb gedacht denk ik dat je de hoek theta (rotatie rond z),de hoek phi (camera tov. Horizon) en de afstand tot de boom wel echt nauwkeurig moet weten om het op te lossen. Als je een berekening maakt voor deze hoeken (ipv. Meten) werkt de onnauwkeurigheid door in de bepaling van de camera positie (^Nr_C2/Center). Daarbij komt ook dat deze fout best veel invloed heeft op de rotatiematrix, een fout van een graad in de hellingshoek geeft over een afstand van 3m al enkele cm’s hoogteverschil.

Voor het opstellen van de projectie van de led op het image plane zul je ook wat experimenten moeten doen. Ik denk dat ik wel een idee heb hoe je de z’ en y’ in de afbeelding kan projecteren maar dan heb je wel de brandpuntsafstand en de kijkhoek van de camera nodig. Daarna lijkt het mij het beste om het probleem in beginsel vooral zo simpel mogelijk te houden. Dus eerst eens kijken of het lukt om een positiebepaling te maken van een led waarbij je de camera exact verticaal plaatst en waar je alle afstanden en rotaties al weet. Hierbij kan je gebruik maken van de hellingshoekmeter en het kompas van je telefoon. Ik kan nog eens kijken of ik iets van studiemateriaal of publicaties kan vinden over dit onderwerp waar de oplossing al eens uitgewerkt is.

[Sgrovert]

Het is weer tijd voor de (jaarlijkse) update.

Vorig jaar ben ik druk geweest met het verbeteren van de Hardware. In 2022 hadden we veel last van storing halverwege de lijn, waardoor de bovenkant van de boom regelmatig verkeerde kleuren had.
Afgelopen jaar heb ik een esp32 met wled geprepareerd, en hier 8 losse led strings aangehangen. Hierdoor zitten de leds in de boom niet meer in 1 grote string, maar zijn er 8 korte strings van 150 / 200 leds. bij storing blijft deze nu beperkt tot een paar leds, ipv. de halve boom.
In 2023 bleken de open connectors van de led strings met name bij regen voor storing te zorgen. Dit jaar is de 3d printer ingezet om connector dopjes te printen, zodat open connects afgedopt kunnen worden. Hopelijk is de hardware voor dit jaar nu klaar en kunnen we draaien met 1200 leds.

De laatste maand ben ik ook weer begonnen met de software. In 2022 heb ik een groot aantal afbeeldingen gemaakt om leds te vinden, en ik wil voordat de lampjes de boom ingaan een 3d model van de 2022 boom klaar hebben.
@TorxWorx @Struikrover , bedankt voor jullie ideeën. Ik heb het afgelopen jaar tijd gehad om even goed na te deken, en ik ga jullie input combineren tot een nieuwe aanpak.

Het plan voor dit jaar.

1. Gebruik het model van @Struikrover als basis model voor de mapping van de leds in de boom.
2. Maak een hoogteprofiel waarbij van elke led de hoogte in de book bekend is.
3. Maar een breedteprofiel waarbij van elke led de afstand tot de stam bekend is.
4. Maak een schatting hoeveel leds er in elke laag zitten die rond de boom gaan
5. Vul het hoogte en breedte profiel en aantal leds per laag in het model in
6. Gebruik het model om een schatting van de cameraposities te maken
7. Gebruik het model om de led detectie in de afbeeldingen te verbeteren. Het model geet aan waar in de afbeelding naar een individuele led gezocht kan worden.
8. Gebruikt de (berekende)cameraposities om de echte posities van de leds in de boom te vinden.

De aanpak van dit jaar word meer big data, waarbij foute led detecties uitgemiddeld zullen worden. All beschikbare data word samengevoegd tot een hoogte en een breedte profiel, waarbij foute detecties uitgemiddeld zullen worden.
In totaal heb ik 54 opnames van verschillende kanten van de boom. (De camera is hierbij ongeveer 10 keer verplaatst, waardoor veel opnames vanuit exacte dezelfde plek gemaakt zijn.)

Resultaten

Led dectectie Dit is een voorbeeld van de boom. (Click om te zoomen) De led detectie heeft de leds gevoden en verbonden met gele lijnen. De blauwe lijn door het centrum in het geschatte midden van de boom.

Hoogte profiel Ik beb begonnen met het opstellen van het hoogte profiel. In elke afbeelding zijn de leds gerangschikt van boven naar beneden. In de afbeelding hiernaast zal de lijst de volgende data bevatten. [57, 58, 59, 56, 61, 60 .... 585, 588, 590]. Led 59 ligt dus lager in de boom dan led 56. Voor alle 54 afbeeldingen heb ik de rangschikking gemaakt en vervolgens samengevoegd tot 1 definitieve rangschikking. Dit profiel ziet er als volgt uit De hoogte is geschaald tussen de 0 en de 1. In dit profiel is te zien dat led 56 ongeveer de laatste led is, en de string richting led 1 weer langzaam omhoog loopt. Dit komt omdat niet alle takken van de boom op dezelfde hoogte zitten. Ook is te zien dat laatste 50 leds (led 550 tot 600) ongeveer 20% van de hoogte van de boom in beslag nemen. Dit komt omdat de leds daar vlak bij de stam zitten en stijl omhoog lopen.

[h3] Breedte detectie [h3]
Na het hoogte profiel ben ik begonnen aan het breedte profiel. Dit is lastiger omdat de afstand van de stam tot de led alleen te bepalen is als de afbeelding precies van opzij genomen is. In de voorbeeld afbeelding is voor led 57 (midden onder) geen afstand te bepalen omdat deze precies tussen de stam en de camera inzit. Voor led 75 (links) is de afstand wel te bepalen. Voor de afstand van deze led ben ik uitgegaan van een uniforme camera. Het aantal pixels tussen de stam en de led kan gezien worden als absolute afstand. Doordat de hoogte al geschaald was en afstanden voor x en y gelijk gesteld zijn, kan er een afstand per pixel bepaald worden. Led 75 ligt op ongeveer 0.3 x de hoogte van de boom.
Omdat er van alle kanten van de boom foto's gemaakt zijn, kan voor elke led bekeken worden in welke foto de afstand tot de stam maximaal is. Dit is een plot van de maximale afstand

De Blauwe lijn in de ruwe data. De rode lijn een 5e orde least sqaure fit. Deze lijn is de breedte van de boom op elke hoogte. De 5e orde is arbitrair, maar invullen van 3, 5, 11, of 22e orde maakt allemaal niet veel uit. De vorm blijft vergelijkbaar.

[h3] Combineren van de data [h3]
Om de data in het model te fitten, heb ik even handmatig vastgesteld welke leds ongeveer boven elkaar liggen. In de voorbeeld afbeelding is dat [57, 142, 218, 296, 365, 424, 470, 490, 523, 549, 563, 590]. Plotten we het model waarbij alle leds per omgang evenredeig verdeeld worden krijgen we deze afbeelding.

Alle leds zijn in de 3d afbeelding geplot. De zwarte lijn verbind de leds die boven elkaar liggen. Deze lijn is redelijk recht wat aantoont dat de fit aardig lijkt op wat er in werkelijkheid gestaan heeft.

Bonus afbeeldingen

Stukje ingezoomd zodat de led id's te zien zijn.


De Boom en het 3d model uit ongeveer dezelfde hoek.

Komdende tijd ga ik even kijken hoe ik bovenelkaar liggende leds automatisch kan detecteren, en vervolgens uitzoeken hoe ik de die informatie kan combineren naar een meer accuraat model.

[Sgrovert]

Vandaag weer een paar kleine stapjes gezet. Ik ben tevreden over het model en denk dat het potentie heeft. De meest logische vervolg stap is het automatisch aanmaken van de lijst van verticaal uitgelijnde leds.

Eerder heb ik al een algoritme gemaakt om leds te verbinden. (Dit zijn de gele lijnen.) Deze feature bleek erg handig om vertikaal uitgelijnde leds te vinden. De kruispunten tussen de blauwe centrumlijn en gele led strings zijn posities die boven elkaar liggen. Voor elke gele lijn die de blauwe kruist heb ik de gevonden led aan de linker en rechterkant gepakt en lineair geïnterpoleerd welke led op het kruispunt ligt.
Als versimpeld voorbeeld, liggen led 7 en 8 links en rechts, dan is led 7.5 de led die in het centrum ligt. Liggen led 7 en 9 aan weerskanten, dan is led 8 in het centrum. Omdat de gevonden led strings niet altijd alle opeenvolgende leds gevonden krijgen, lost het interpoleren het probleem van missende id's op.
Ik heb besloten om niet af te ronden, omdat de vertikaal uitgelijnde leds later alleen gebruikt zullen worden om een rotatiehoek in het model te berekenen. Voor deze berekening is het niet nodig om met vaste led id's te werken, maar kan er prima met fracties gewerkt worden.

Ter validatie een vergelijking wat ik met de hand deed, en wat het nieuwe algoritme geeft:
hand : [57, 142, 218, 296, 365, 424, 470, 490, 523, 549, 563, 590]
algo : [56.80, 142.00, 218.00, 294.84, 364.76, 366.27, 366.09, 424.02, 469.22, 489.41, 519.00, 522.86, 522.49, 525.48, 512.92, 563.18, 586.26]

Dit is ongefilterde data. Waardes "364.76", "366.27", "366.09" worden gevonden omdat de leds daar via een tak recht richting de stam gaan. Ik ben nog bezig om te kijken hoe ik dit verder kan opwerken om de fit van het model aan te kunnen passen.


Tijdens het bekijken van de data kwam ik nog een interessante foto uit een andere hoek tegen.


Deze foto is interessant omdat vanaf de grond de bovenkant van de boom niet echt duidelijk is. Deze foto geeft veel beter weer hoe het hoog in de boom uitziet.
In deze foto is ook de stam te zien. De blauwe lijn zit niet heel ver uit het centrum. Ook dit algoritme word hiermee gevalideerd.
Het laatste wat opvalt, is dat er een volledige ronde loop gevonden is. Led 438 t/m 496 lijken 2x rond de boom te gaan. Hier zal ik strak rekening mee moeten houden.
De gevonden center leds zijn voor deze afbeelding
[411.82, 459.53, 474.16, 485.08, 513.37, 539.32, 538.56, 541.83, 541.40, 543.69, 543.49, 548.70, 549.73, 555.63, 568.00, 568.24, 568.84, 580.73, 584.54, 587.54, 587.61, 589.76]

[Sgrovert]

De laatste paar dagen heb ik een paar mini stapjes gezet. Ik ben druk geweest met het automatisch detecteren van hoe snel de leds om de boom roteren, of in andere woorden, hoeveel leds zitten er per laag die 1x rond de boom roteert.
Dit heb ik weer aangepakt door alle beschikbare data samen te nemen. Tijdens het detecteren van een led string kruisen deze strings regelmatig het geschatte midden van de boom. Kijkend naar oplopende led id's zal de kruising van links naar rechts, of van rechts naar links plaatsvinden. Door te kijken naar welke van de 2 richtingen het vaakst voorkomt, kan bepaald worden in welke richting de string om de boom gedraaid zit.
Vervolgens heb ik alleen de kruisingen in de meest voorkomende richting genomen en per afbeelding bepaald welk led id er per laag kruist. Dit geeft per afbeelding een lijst als

Met deze lijst kan er bepaald worden hoeveel leds er in een laag zitten. Kijken we naar de eerste kolom zal er voor led 135 t/m 288 geschat worden dat er 288-135 = 153 leds in de laag zitten. Voor led 288 t/m 363 zitten er 75 leds in de laag.
Op deze manier heb ik voor alle 600 leds bepaald hoeveel leds er in de laag zitten en van alle schattingen de mediaan genomen. Dit geeft een vrij accurate schatting.
In onderstaande afbeelding heb ik een bovenaanzicht van de posities van de leds geplot.

De leds volgen het spiraalmodel en de afstand tot de stam is de breedte schatting van een paar posts terug. De gekleurde lijnen zijn camera zichtlijnen van verbonden leds die in lijn met de stam liggen. (de kolommen uit de verticals afbeelding). Bij een perfect model zouden alle camera lijnen recht vanuit de stam naar buiten lopen.
Kijken we naar de blauwe, gele en cyaan lijn aan de rechterkant van het model, dan volgen al deze lijnen een redelijk vergelijkbaar patroon. Helemaal buiten aan lijkt de lijn vrij aardig richting het centrum te lopen. In de 3e rotatie maken ze een flinke knik naar rechts, en daarna snel terug naar links. Het lijkt alsof in deze laag de schatting van het aantal leds er een paar naast zit, waardoor alles opschuift.
In het midden van de boom lijken de lijnen rondom de top te gaan draaien. Ik heb hier 2 verklaringen voor. Het model van de breedte van de boom wijkt helemaal bovenin een stukje af. Er zitten best veel leds rondom de stam gedraaid (afstand 0), maar de schatting van de breedte word nooit helemaal 0. Hierdoor liggen deze leds niet ver genoeg naar binnen. Daarnaast is de hoek van de leds bij led 1 (helemaal buiten) begonnen. Voor elke volgende led is hier een nieuwe geschatte hoek bij opgeteld, waardoor elk bij elke volgende led een grotere fout ontstaat. Het lijkt alsof er een drift in zit waarbij de rotatie net wat te sterk geschat wordt.

Komende dagen ga ik kijken of ik de drift wegkrijg en een beter fit kan krijgen. Ik wil kijken of the lukt om een fit te maken, waarbij alle lijnen bijna recht naar het midden van de boom lopen.

[Sgrovert]

Het even werk, maar ik ben weer een stapje verder.
Het is gelukt om aan de hand van de camera beelden een betere schatting van het model kunnen maken. In onderstaande afbeeldingen staat een bovenaanzicht van de boom. Het model van de afstand van de led tot de stam heb ik niet meer veranderd. Bij het roteren van de led posities rondom de stam heb ik in de vorige post een gemiddelde geschatte positie gebruikt. In het nieuwe model heb ik ook de echte camera beelden gebruikt. Leds die in een camera positie boven elkaar liggen, liggen in een bovenaanzicht in een rechte lijn van de stam naar buiten. In een bovenaanzicht kan de positie van de led in pool coördinaten weergegeven worden. Het assenstelsel begint op een willekeurig punt in de boom. Vervolgens maken alle leds een hoek tussen de 0 en de 2 pi.
Een camera staat op een vast punt in dit stelsel. (bv 0.95 pi). Dit betekent dat alle leds die in lijn met de stam liggen, allemaal hoek 0.95 krijgen. De hoeken van de camera heb ik bepaald aan de hand van het model met de geschatte led hoeken.

In deze afbeeldingen heb ik het originele model (links) en het model met gecorrigeerde camera data (rechts) naast elkaar gezet. Naar mijn mening zijn de lijnen in het rechter model inderdaad rechter. Ter indicatie heb ik voor elke lijn ook de geschatte hoek van de camera als punt geplot.

Origineel

Gecorrigeerd

Het model geeft nu x, y, z posities van de leds. Komende dagen hoop ik mbv. een matrix en een smallest sqaure fit de posities van de camera's te vinden. Het helpt hierbij dat ik nu een vrij aardige schatting van de positie van de camera heb.

[Sgrovert]

TorxWorx schreef op maandag 30 oktober 2023 @ 20:38:
deel 2:
De makkelijkste manier om dit probleem op te lossen zou zijn een vector opstellen van het camerabrandpunt tot het denkbeeldige image vlak, daarna deze vector normaliseren (lengte = 1). Met deze vectoren voor beide C’s zou je in theorie het snijpunt kunnen bepalen door deze te lineariseren, je weet immers dat de positie van de led in het N frame vanuit beide standpunten overeen moet komen. In vector vorm
^Nr_C1/Center + a * ^Nr_{image 1/C1} = ^Nr_C2/Center + b * ^Nr_{image 2/C2}
Deze vergelijking oplossen voor a en b zorgt ervoor dat je in theorie de exacte positie hebt van de led.

Met de geschatte positie van de leds wil ik nu met deze stap aan de slag. Ik wil het alleen andersom doen. Aan de hand van de led posities wil ik nu de camera positie gaan bepalen. Vandaag heb ik research gedaan en gekeken naar wat hierover op het net te vinden is. Tijdens mijn zoektocht ben ik het begrip 'point cloud' tegengekomen. Dit word meestal in de context van het detecteren van 3d objecten gebruikt, maar komt ook behoorlijk overeen met mijn probleem. Indien de leds solid points op de boom waren, zou er een 3d object van gemaakt kunnen worden.
Bij een point cloud is het terugvinden van een camera positie a.d.h. van de punten in de cloud iets wat al gedaan is. Ik heb o.a. op de site van openCV deze link gevonden https://docs.opencv.org/4.10.0/d5/d1f/calib3d_solvePnP.html

The solvePnP and related functions estimate the object pose given a set of object points, their corresponding image projections, as well as the camera intrinsic matrix and the distortion coefficients,

Kijkend naar de afbeelding die erbij staat lijkt dit vrij behoorlijk op wat ik aan het doen ben.

u en v weet ik. Dat zijn de x,y coordinaat in het camera beeld.
r en t zijn de Rotatie en translatie matrix. Deze moeten bepaald worden.
x, y, z zijn bekend. Dit zijn de coördinaten van de leds in het model.

Alleen van Fz, Fy, Cz en Cy weet ik niet goed wat ik ermee moet. Dit zijn camera parameters, maar ik weet nog niet wat ik hier mee moet.

Hier lijkt een implementatie voorbeeld te staan https://www.delftstack.com/howto/python/opencv-solvepnp/
Cz en Cy staan voor Camera center. Fz en Fy zijn hier focal_length . Nu weet ik waar C en F voor staan, maar nog steeds niet wat deze parameters betekenen.
Dit voorbeeld lijkt wel te bevestigen dat functie cv2.solvePnP te rotatie en translatie matrix uitrekend.

[ Voor 7% gewijzigd door Sgrovert op 07-11-2024 23:40 ]

[KabouterSuper]

Helpt dit plaatje om C en F te begrijpen?
https://docs.opencv.org/3.4/d5/d1f/calib3d_solvePnP.html
Cx en Cy lijken mij de coördinaten van de camera. Fx en Fx representeren de richting.

[Tux3.14]

Good old Tweakers vibes. Dit dus is waarom ik naar Tweakers ga.
Succes man! Benieuwd naar het eind resultaat.

*gaat topic volgen.

[TorxWorx]

[b]Sgrovert schreef op donderdag 7 november 2024 @ 23:29:

Alleen van Fz, Fy, Cz en Cy weet ik niet goed wat ik ermee moet. Dit zijn camera parameters, maar ik weet nog niet wat ik hier mee moet.

Hier lijkt een implementatie voorbeeld te staan https://www.delftstack.com/howto/python/opencv-solvepnp/
Cz en Cy staan voor Camera center. Fz en Fy zijn hier focal_length . Nu weet ik waar C en F voor staan, maar nog steeds niet wat deze parameters betekenen.
Dit voorbeeld lijkt wel te bevestigen dat functie cv2.solvePnP te rotatie en translatie matrix uitrekend.

Met f_x en f_y bereken je eigenlijk de distorsie van de camera. Als het goed is zou je die op deze manier moeten kunnen berekenen:
De makkelijkste manier om alfa en bèta te bepalen is denk ik door een loodrechte foto te nemen van een vierkant vlak. Bijvoorbeeld een 1x1m vierkant op de muur en een foto op 2m afstand. Voor nu zou ik aannemen dat thèta = 90graden en s = 0.

[Sgrovert]

Geïnspireerd door deze tutorial https://docs.opencv.org/4...orial_py_calibration.html heb ik een poging gedaan om een calibration matrix te maken.
Ik heb de code maar gelijk even naar het project geupload https://github.com/Lahaij...en_cv/opencv_calibrate.py

Ik heb mijn schaakbord erbij gepakt en een set images gemaakt die lijken om de methode die in de camera calibration tutorial gebruikt is. Volgens de documentatie heeft een camera exact 1 camera calibration matrix.


Dit zijn mijn resultaten:

code:

[[629.1960281    0.         300.84679464]
 [  0.         627.90874673 239.12865673]
 [  0.           0.           1.        ]]

code:

[[446.24217428   0.         280.85878585]
 [  0.         431.57415893 241.12520624]
 [  0.           0.           1.        ]]

De Webcam heeft een resolutie van 640 x 480. Het centrum zou dus op 320 x 240 liggen.

Kijkend naar de post van @TorxWorx , zijn Cx en Cy dus 300 , 240 en Fx, Fy zijn bijna aan elkaar gelijk. Dit klopt met mijn verwachting dat de webcam ongeveer dezelfde hoek in x en y heeft.
Ik snap alleen niet goed waarom Fx in de eerste afbeelding 629 en in de 2e 446 is. Enige verklaring die ik kan bedenken is dat het bord in de 2e afbeelding verder van de camera weg is. Dit zou misschien kunnen komen doordat de functie x = f(X/Z) de Z meeneemt, welke dan dus de afstand tot het object is.

Mocht deze aanname kloppen, denk ik dat een geldige matrix voor mijn camera als volgt uitziet

code:

[1,  0,  320]
[0,  1,  240]
[0,   0,   1]

Ik denk dat de camera matrix vooral bedoeld is om vervorming van een pin hole camera terug te rekenen, maar wij een webcam niet veel invloed heeft. De waardes van Fx en Fy mag ik waarschijnlijk op 1 zetten, waarna later de Translatie matrix hiervoor corrigeerd, door de camera verder weg te plaatsen.

[Sgrovert]

Vandaag heb ik eindelijk weer tijd gehad om aan het projectje te werken.
Dit jaar is eindelijk de stroomverdeling op order en de boom is nu al weken storingsvrij en stabiel.
Met het wisselen naar een ESP32 met WLED is wel de 'oude' implementatie voor het aansturen van de boom niet meer werkend.
Ik ben ondertussen bezig uit te zoeken hoe de boom in WLED vanuit python aan te sturen is.
We gebruiken sinds vorig jaar het LedFX project om de boom audio reactive te maken. Dit project is geschreven in python en de source code is beschikbaar. Vandaag heb ik de DDPDevice class uit het project gehaald welke ik ga gebruiken om een eigen uitbreiding op te maken, zodat deze samen werkt met de webcam en ik de huidige boom opnieuw op kan meten.

Hier is een filmpje waarin te zien is dat de boom reageert op het starten van het test script.
WLED heeft een standaard programma lopen, en switched naar 'DDP' mode zolang er nieuwe data updates naar de boom verstuurd worden. Zodra er geen nieuwe data pakketjes meer naar de boom gaan, switched deze terug naar zijn standaard programma.

Hier staat de WLED ddp documentatie. Deze verwijst naar de http://www.3waylabs.com/ddp/ als source. Met 1050 leds in de boom zijn er 3 pakketten nodig om alle leds een update te geven. 2x 480 leds, 1x 90 leds. De headers van deze pakketten ziet er als volgt uit

code:

flag, sq, Type, Out, Offset      ,   Lenght  
[ 64, 14,    1,   1, 0, 0, 0, 0  ,   5, 160]
[ 64, 14,    1,   1, 0, 0, 5, 160,   5, 160]
[ 65, 14,    1,   1, 0, 0, 11, 64,   1, 14 ]

The flag is een binaire representatie van de flags. [V V x T S R Q P].
V is een versie nummer, P is een push flag welke aangeeft dat alle data packages verstuurd zijn en de boom zijn kleur mag veranderen.
Kijken naar de data hebben de eerste 2 pakken waarde 64 (1000000). Het 3e pakket heeft waarde 1000001, wat dus versie 1 plus the push bit is. Na dit pakket zal de boom dus van kleur veranderen.
sq is de sequence en deze is altijd tussen de 1 en 15.
Type = 1. Deze zet het protocol of RBG. Dit bepaald hoe de verzonden data geinterpreteerd moet worden.
Out = 1. Default output device.
Offset. Deze heeft 4 bytes. 0,0,5,160 zou dus 5*256+160 zijn, wat gelijk is aan 3x480. (RGB waarde voor 480 leds).
Length. De lengte van de data in het pakket.

Met deze informatie zou het mogelijk zijn om zelf UDP pakketten te maken, maar voor het gemak gebruik ik voorlopig even de LedFx implementatie.
Ik moet alleen wel rekening houden met het feit dat na het versturen van een Frame, de WLED de output maar kort laat zien voor deze terug valt op zijn basis programma. Voor animaties is dit geen issue, daar deze meerdere fps zullen krijgen, voor het maken van de foto's om de boom in te meten kan dit een issue zijn.