T-Shirt Banner
Sidan 2 av 14 FörstaFörsta 123412 ... SistaSista
Resultat 11 till 20 av 138

Ämne: Nytt projekt igen! Hastighetsmätning av helikoptern.

  1. #11
    Du kommer med idéer du Inget fel med det. Faktiskt var det med motion-tracking en "efter-grej", kom hem med en massa rådata och märkte att det vart skit-jobbigt att hitta i datan. Men jag vill spara all rå-data varje flight av anledningen att det är lätt att efterkolla så att kamerorna gör rätt (första versionen skall överhuvudtaget inte ha realtime mätning), utan man gör sina flighter och sätter sig vid datorn och letar upp bilderna själv (med hjälp av motion-tracking går det på sekunder). Utan komprimering är rådatan ca 20MB / sekund, så det är en del.

    Anledningen till att jag gör så här är helt enkelt den att jag vill börja någonstans med ett rimligt projekt, inte ta på sig mer än nödvändigt. För att senare ha möjlighet att förbättra med samma grund. Som t.ex realtime mätning.

    Jag har faktiskt tänkt på interpolering/smoothing av tiden, men jag tror inte att det är rätt val i det här fallet. Även om jag vet att två bildrutor är 11ms mellan varandra så är det inget jag riktigt kan använda. Det handlar om att synca två oberoende kameror. Som visserligen har klocka syncad ner till en millisekund. interpolering kan nog faktiskt försämra dom faktiska tiderna. Men det är lite öppet för diskussion och testning. Jag väljer inte till att börja med, att få ner jittret är viktigast. Ligger väl på max 7-8ms nu ca.. Ofta mycket mindre än så. Happas att nya PI 3 skall ta ner det ännu mer. PI 2 svarade bra på lite överklockning.
    Senast redigerat av Linus Larsson den 2016-03-15 klockan 11:19.
    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

  2. #12
    Forum-räv
    Reg.datum
    Mar 2015
    Ort
    Stockholm
    Inlägg
    1 114
    Citat Ursprungligen postat av Linus Larsson Visa inlägg
    Du kommer med idéer du Inget fel med det. Faktiskt var det med motion-tracking en "efter-grej", kom hem med en massa rådata och märkte att det vart skit-jobbigt att hitta i datan. Men jag vill spara all rå-data varje flight av anledningen att det är lätt att efterkolla så att kamerorna gör rätt (första versionen skall överhuvudtaget inte ha realtime mätning), utan man gör sina flighter och sätter sig vid datorn och letar upp bilderna själv (med hjälp av motion-tracking går det på sekunder). Utan komprimering är rådatan ca 20MB / sekund, så det är en del.

    Anledningen till att jag gör så här är helt enkelt den att jag vill börja någonstans med ett rimligt projekt, inte ta på sig mer än nödvändigt. För att senare ha möjlighet att förbättra med samma grund. Som t.ex realtime mätning.

    Jag har faktiskt tänkt på interpolering/smoothing av tiden, men jag tror inte att det är rätt val i det här fallet. Även om jag vet att två bildrutor är 11ms mellan varandra så är det inget jag riktigt kan använda. Det handlar om att synca två oberoende kameror. Som visserligen har klocka syncad ner till en millisekund. interpolering kan nog faktiskt försämra dom faktiska tiderna. Men det är lite öppet för diskussion och testning. Jag väljer inte till att börja med, att få ner jittret är viktigast. Ligger väl på max 7-8ms nu ca.. Ofta mycket mindre än så. Happas att nya PI 3 skall ta ner det ännu mer. PI 2 svarade bra på lite överklockning.
    Det jag menade med interpolering var alltså att du plottar tid som en funktion över position, tar och bestämmer t.ex. en spline som går genom de punkterna, och helt enkelt ser vad tiden är på mittlinjen. Då borde du få en hyfsat bra timestamp, givet att hastigheten är någorlunda konstant

    Hur har du satt tråd/process-prioritet? Om man är lite smart med hur man gör det så kan man nog få upp prestandan lite till. Man skulle även kunna vara noga med vilken scheduler man kör i kerneln, men det är nog lite överkurs :P
    Logo 700 / 600 SX v2 / 550 // Gaui X7 // Soxos 600 // Goblin Urukay
    VBar Control och Spektrum DX7 g2

  3. #13
    Citat Ursprungligen postat av togi Visa inlägg
    Det jag menade med interpolering var alltså att du plottar tid som en funktion över position, tar och bestämmer t.ex. en spline som går genom de punkterna, och helt enkelt ser vad tiden är på mittlinjen. Då borde du få en hyfsat bra timestamp, givet att hastigheten är någorlunda konstant
    Det här räcker inte. Kan inte förutsätta att man kör konstant hastighet.

    Citat Ursprungligen postat av togi Visa inlägg
    Hur har du satt tråd/process-prioritet? Om man är lite smart med hur man gör det så kan man nog få upp prestandan lite till. Man skulle även kunna vara noga med vilken scheduler man kör i kerneln, men det är nog lite överkurs :P
    Jodå, allt detta är gjort och provat. PI:n svarade sådär, det gjorde siit, det gjorde det. Men bäst svarade den på överklockning. Jag känner att med dessa delar är jag klar för tillfället. Möjligen byta hårvara till PI 3 då. Nästa steg som jag vill få in (När jag plockar upp den här påsen igen) är att fånga bilden (sätta timestamp) ännu snabbare från att den lämnar kameran, men då måste jag in i det som heter "mmal-libet" och rota, och det kan vänta tills nästa version.

    Det är ju också så att kameran är en egen enhet med egen klockfrekvens osv. Två kameror tar inte bilden samtidigt, och det förutsätter jag inte, jag förutsätter inte ens att kameran tar i 90FPS, för jag tror inte den gör det (har läst på lite, två kemeror kan diffa lite, lite). Men någonstans blir det ett "leap of faith". Jag vill få det så litet som möjligt. Och jag vill ha möjlighet att i framtiden förbättra.
    Senast redigerat av Linus Larsson den 2016-03-15 klockan 12:08.
    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

  4. #14
    Forum-räv
    Reg.datum
    Mar 2015
    Ort
    Stockholm
    Inlägg
    1 114
    Citat Ursprungligen postat av Linus Larsson Visa inlägg
    Det här räcker inte. Kan inte förutsätta att man kör konstant hastighet.
    Men, precis runt mitten så borde man ändå kunna anta det, eller hur? Jag menar alltså bara att du tar de närmaste punkterna runt mitten av bilden.
    Logo 700 / 600 SX v2 / 550 // Gaui X7 // Soxos 600 // Goblin Urukay
    VBar Control och Spektrum DX7 g2

  5. #15
    Forum-räv
    Reg.datum
    Mar 2015
    Ort
    Stockholm
    Inlägg
    1 114
    En till idé! Sätt några lysdioder så att de syns på bilden kameran tar. Sen så blinkar du ut en binär timestamp med dem. Då kan du mäta och kompensera för latency, och det spelar inte så stor roll vad den är
    Logo 700 / 600 SX v2 / 550 // Gaui X7 // Soxos 600 // Goblin Urukay
    VBar Control och Spektrum DX7 g2

  6. #16
    Jo det är möjligt att du har rätt här. Det blir ju någon form av smoothing av timestamps i slutändan. Som sagt, jag vet ju att det är väldigt nära 55ms om man tar 5 bilder efter varandra. Jag skall ge det en tanke, och jag har redan gett det en tanke. Jag kommer inte göra det i V1. Jag har en implementation som är redo för real testing vad gäller detta.

    Det är bra att du kommer med idéer och du verkar duktig på sånt som faktiskt är viktigt för det här (Du får jättegärna vara med på riktigt i ett senare skede, behöver få upp lite github osv först). För övrig alltid bra att jag får försvara min implementation (Jag har inga problem med att bli överbevisad osv, då lär jag mig något). Jag försöker verkligen få det här så exakt som överhuvudtaget är möjligt på den ringa hårdvara jag har att köra på. En av grundbultarna är att det här får inte kosta skjortan. Det skall gå att bygga för en rimlig peng av någon som vill prova på äkta speed-flygning.

    Nästa steg är att "färdigställa" GUI:t. Det är enkelt, gjort i python. Samt att jag egentligen behöver ett trevligare API för att prata med kamerorna... Jag gör en killall för att stänga av dom nu
    Senast redigerat av Linus Larsson den 2016-03-15 klockan 12:34.
    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

  7. #17
    Aktiv användare
    Reg.datum
    Sep 2013
    Ort
    Linköping
    Inlägg
    201
    Vilka möjligheter har du att programmera bildområdet i kameran och påverka utläsningshastigheten? Skulle det gå att bara exponera/läsa ut en linje eller kolumn och få en mycket högre frame-rate? (Som en målfotokamera/linjekamera.) Du borde kunna trigga på att några pixlar i linjen ändras och på det sättet detektera att helikoptern nått mitten av kameran. Förutsätter förstås att bildfrekvensen är tillräckligt hög så att inte helin hinner passera mellan två bilder.

    Har du klurat på rolling-shutter, dvs att kameran (kanske) inte tar hela bilden på samma gång? Hur mycket skillnad i hastighet blir det om helin flyger in i den övre delen av bilden i första kameran och i nedre delen av bilden i den andra kameran? Behöver man kompensera för detta? Vrida kameran?

    (Kul projekt förresten...)
    Mikado Logo 550 o Robbe Bell UH-1D

  8. #18
    Citat Ursprungligen postat av tsv Visa inlägg
    Vilka möjligheter har du att programmera bildområdet i kameran och påverka utläsningshastigheten? Skulle det gå att bara exponera/läsa ut en linje eller kolumn och få en mycket högre frame-rate? (Som en målfotokamera/linjekamera.) Du borde kunna trigga på att några pixlar i linjen ändras och på det sättet detektera att helikoptern nått mitten av kameran. Förutsätter förstås att bildfrekvensen är tillräckligt hög så att inte helin hinner passera mellan två bilder.
    Själva hårdvaran i kameran skall vara god för 120FPS. Dock finns bara 90FPS tillgängligt i PI biblioteken. Och det får jag ut. Vad jag förstår är det inte helt lätt för devarna att komma över dokumentation. Men är iallafall inte möjligt med mer än 120FPS. Hursom, skriva drivrutin är inget område jag tänker ge mig in i

    Citat Ursprungligen postat av tsv Visa inlägg
    Har du klurat på rolling-shutter, dvs att kameran (kanske) inte tar hela bilden på samma gång? Hur mycket skillnad i hastighet blir det om helin flyger in i den övre delen av bilden i första kameran och i nedre delen av bilden i den andra kameran? Behöver man kompensera för detta? Vrida kameran?
    Svar nej, inte tänkt på. Den har ju helt klart en grym shutter-speed. Man ser bladen utan motion-blur i luften på stillbilder. Men jag kanske borde vrida kameran 90 grader för att ta bort detta möjliga problem. Som sagt, varje millisekund räknas. Sen tror jag väl iofs att du får inte dyka för att tiden skall räknas, och då elimineras ju problemet med regler...
    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

  9. #19
    Kolla slutet på denna video. Det säger iofs inte så mycket. Man skulle nog inte se 2ms skillnad i rolling shutter. Jag skall läsa på lite om det. Vrida bilden är inga problem.

    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

  10. #20
    Jag förstår ju att det fortfarande blir skew om man vrider kameran, men jag kör på teorin att är det exakt samma skew mellan kamerorna spelar det inte någon roll om det är 10 minuter..
    T-Rex 700E DFC - Logo 690SX - Goblin 700 (Hello kitty) - VBar Control
    V-Bar Control flight analyzer

Behörigheter för att posta

  • Du får inte posta nya ämnen
  • Du får inte posta svar
  • Du får inte posta bifogade filer
  • Du får inte redigera dina inlägg
  •