lillahuset skrev:Men varför inte prata om milligram då? Eller är det så att vapenfetischisterna är så USA-inspirerade att de anammar den USAnska kulturen med hull och hår. Använder ni också BTU i stället för Joule? Eller foot-candle i stället för lux. Inse att det bara är tre U-länder i världen som inte har infört SI-systemet. Ni bor inte i något av dem. Antar jag.
Äsh, det är väl som med båtmuppar som envisas med knop och styrbord Jag morrade lite i början och muttrade km/h men, mjae.
Vad roligt! Jag har gjort precis det här. Jag har ett javaprogram på en paj med kameramodul som tittar på en display på en Zoller verktygsinmätningsapparat. Den koden har jag lagt ner mycket svett och möda på men jag delar gärna med mig av den om du är intresserad.
Säkerheten ligger nånstans mellan 99 och 100%. Jag har tänkt att jobba vidare genom att köra flera exponeringar och medelvärdesbilda dem för att få ett ännu säkrare resultat. Jag misstänker att det beror på att det är lysrörsbelysningen som påverkar med sitt 50Hz-flimmer. I mitt fall så är det en decimalpunkt som kan störa. Vi använder den som sagt för att mäta in verktyg till våra fräsmaskiner och svarvar. Programmet gör om längderna till verktygsfiler för de olika maskinerna så att man slipper knappa in dem för hand. Väldigt tidsbesparande.
meconer skrev:Jag har ett javaprogram på en paj med kameramodul som tittar på en display... Den koden har jag lagt ner mycket svett och möda på men jag delar gärna med mig av den om du är intresserad.
Spännande! Vad är det för kameramodul du använder? Bara java? Hur många rader kod blev det?
Jag använder raspberry pi:s standardkameramodul och det är bara java. Det är nog ett par tusen rader men då ingår koden för användargränssnittet och översättning till de olika formaten som våra maskiner använder. Javaprogrammet använder ett bashscript för att ta själva bilden som sedan läses in till en BufferedImage i Java.
Avläsningen av bilden tar några sekunder och det är tillräckligt fort för att den skall vara avklarad när man har bytt till nästa verktyg. Vad jag förstår så använder Java:s BufferedImage sig av pajens grafikhårdvara så länge man håller sig till vissa regler. Jag tänkte som sagt byta till en Pi 2:a för att få det lite snabbare men jag är inte helt säker på att det faktiskt gör någon skillnad eftersom det såvitt jag vet är samma grafikhårdvara.
Tänkte att om du porterade koden till C så kanske du kan få en rejäl hastighetshöjning. Java har väl en del C++ egenskaper och framföralllt så är det väl som oftast bytecode interpreterat.
Nu behöver det ju inte gå fortare än vad det gör. Det jag tänker mest på är hur jag skall förbättra avläsningssäkerheten ytterligare. Som det är nu så får man korrekta avläsningar NÄSTAN varenda gång. Det är inte hundra procent men väldigt nära. Tillräckligt nära för att de som använder det skall glömma bort att dubbelkolla. På skärmen syns både bilden och det avlästa värdet väldigt tydligt men tittar man inte där så ser man inte om det blir fel.
Jag misstänker att jag det är ett flimmer som påverkar. Dels från lysrören i lokalen och dels på displayen. Beroende på slutartiden när bilden tas så blir det olika exponeringar och jag tror att det kan finnas lite problem där. Jag har en idé om att ta flera bilder och medelvärdesbilda så att man minskar påverkan från flimret. Å andra sidan så finns då risken att siffrorna kan stå och fladdra lite mellan olika värden och ytterligare ställa till problem.
Hastigheten ser jag alltså inte som något stort bekymmer och med tanke på att det finns så mycket bra bildhanteringsfunktioner i Java som använder sig av grafikhårdvaran så är det inte säkert att det går fortare med c eller c++. Om man nu inte lyckas hitta något bra sätt att använda hårdvaran där också förstås. Dessutom är min vana att programmera i Java betydligt större än i c-varianterna just nu.
Något som är väldigt smidigt är också att java är mer plattformsoberoende än c och c++. Jag har gjort hela utvecklingen i netbeans på min windows-pc och flyttar direkt ned koden till pajen utan ändringar. Det enda som skiljer är scriptet som tar bilden. På pajen så tas en riktig bild men på pc:n är det bara en dummy så jag kör med en och samma bild hela tiden.
Jag vet inte hur det är nu men när jag satte ihop systemet så var exponeringen automatisk. Det var ett tag sen och med reservation för minnesfel i min hjärna så var det så att man kunde påverka exponeringen, men bara i förhållande till automatiken, dvs plus eller minus i olika steg. Det kan vara ändrat nu. Man använde programmet raspistill för att ta bilder. Nu verkar det finnas fler möjligheter så det blir till att kolla upp det när jag gör min nästa version.
Jag har en idé om att ta flera bilder och medelvärdesbilda så att man minskar påverkan från flimret. Å andra sidan så finns då risken att siffrorna kan stå och fladdra lite mellan olika värden och ytterligare ställa till problem.
Gör tvärtom då, ta ett antal bilder och räkna ut värdet var för sig, sen medelvärdesbilda. Då borde det även gå att lista ut ifall nån av avläsningarna är skräp helt o hållet när man har några att jämföra med.
Jag morrade lite i början och muttrade km/h men, mjae.
