Automatisk krutdispenser

[Öskar]

Efter några rediga kliv framåt så är det dags för ett kliv bakåt . . . ett stort kliv . . . bakåt . . .

Testarbetet har lett fram till flera rättningar av fel och brister. Den har också medfört att jag kommit till en betydande insikt: kalibreringslogiken (grovkalibreringen) måste göras om från grunden. Jag har övergett iden med att använda de två röda punkterna som underlag för grovkalibrering.

Tanken var att det skulle gå att lösa kalibreringen med enkel logik då inget annat rött skulle förekomma i bild. Jag har nu insett att jobba med färg är extremt beräkningsintensivt. En bild i färg innehåller 65 536 gånger mer data (vid normal färgupplösning) jämfört med motsvarande bild i gråskala.

Den nuvarande kalibreringslogiken är förvisso väldigt enkel, men allt för långsam under vissa ljusförhållanden. Därtill misslyckas kalibreringen under vissa omständigheter. Det beror sannolikt på att jag duttat dit de röda prickarna med en spritpenna. Prickarna är inte homogent färgade. Kanske hade fungerat om de haft en enhetlig färg, men det hade ändå aldrig blivit en stabil och feltolerant kalibrering med tillräcklig prestanda.

Med de kunskaper jag har nu, så inser jag att det var puckat att försöka jobba med bildanalys i färg. Det positiva är att jag lärt mig en hel del.

Jag kommer att pröva att jobba med svartvit-konverterade bilder istället. Det blir betydligt mer komplicerad logik då det kommer att finnas flera ovidkommande vita objekt i bilden. Jag måste analysera och jämföra dessa vita ytor för att kunna fastställa vilka av dem som representerar skala och bom. Det kan låta enkelt, men det är det inte. En dator saknar helt intuition. Jag kommer inte heller att kunna beta av objekt för objekt isolerat från varandra. Huruvida ett vitt område är relevant eller inte, är helt avhängigt av de andra (ännu ej identifierade) relevanta områdena. Hur de vita områdena ser ut beror också på tröskelvärdet som används vid konvertering. Ett tröskelvärde som måste provas fram under kalibreringsprocessen, och som kommer att variera med rådande ljusförhållanden.

Det känns som att allt jag gjort hittills är enkelt i jämförelse med det jag nu står inför. Samtidigt är kalibreringen helt avgörande för om detta projekt kommer att lyckas eller inte. Ingen kalibrering = ingen automatisk krutdispenser som uppfyller mina krav. Problemet är naturligtvis inte oöverstigligt, men för mig är det en utmaning.

Återkommen i frågan när jag förstår mer.

Test och dokumentation 9 timmar.

[Öskar]

Budgetavstämning och lärdomar

Pengar (SEK)
webcamera 27,79
stegmotor 16,40
axeladapter 11,26
LCD 12,39
Summa 67,84
Budget 200,00
Tillgodo 132,16

Tid krutdispenser (timmar)
trickler 0,50
RPi installation 1,00
image recognition studier 15,00
RPi GPIO experiment 1,00
kameraexperiment 3,00
vågkonsoll 0,25
kameramontage 2,50
vågmodifieringar 0,25
kamera/videoinspelning 1,50
mjukvaruutveckling 27,00
hårdvarubygge stegmotor 0,50
hårdvarubygge rpi knappar 0,50
stegmotorexperiment 2,50
test och dokumentation 9,00
Summa 64,50
Budget 80,00
Tillgodo 15,50

Tid studier (timmar)
crash course 6,00
RPi hårdvarustudier 2,00
python studier 15,00
python studier 55,00
Summa 78,00
Budget 100,00
Tillgodo 22,00

Lärdomar
1) Att lära sig Pyhton är jobbigare än att snyta näsan.
2) Satsa på en dyrare kamera.
3) Image recognition är inte helt trivialt.
4) Studierna i Python och image recognition betalar sig.
5) Satsa på en lite kraftigare stegmotor som kan leverera ett högt varvtal på drivaxeln.

[fonkystuff]

Kämpa Öskar! Bra tråd!

[Öskar]

Först ett tillkännagivande:
Jag har slutat utveckla egen image recognition logik. Det var spännande och lärorikt att ”göra själv”, men det tar alldeles för lång tid. Från och med nu kommer jag bara att använda OpenCV. Precisionsmässigt är de jämbördiga, men prestandamässigt utklassar OpenCV min kod med hästlängder. Därtill går det mycket fortare att utveckla med OpenCV (andra tappra själar har ju redan gjort hästjobbet). Jag tackar teamet bakom OpenCV.

Sedan ett konstaterande:
Det är tur att man är så dum att man inte förstår vad man ger sig in på . . . annars hade man aldrig försökt!

Nu till saken:
Naturens misstag är nu korrigerade (grovkalibreringen omgjord från grunden)

Grovkalibreringen är den del av programmet som tar reda på (ungefär) var i bilden skal-etiketterna finns. Utifrån den informationen bestämmer programmet vilka delar av bilden som är relevanta att analysera för att positionera skala och bom.

orginal.jpg

Grovkalibreringen börjar med att konvertera bilden till gråskala.

gray.jpg

Därefter grumlas bilden för att tvätta bort ”överflöd av konturer”

blur.jpg

Därefter konverteras bilden 180 gånger till svartvitt. Alla gånger med olika s.k. tröskelvärde (se tidigare inlägg). För varje svartvit-konverterad bild så framtas en ”minsta-omslutande-cirkel” för bildens samtliga ”kontur-områden”. Nedan visas effekten av två ”extrema” tröskelvärden.

threshold_40_circles.jpg

threshold_250_circles.jpg

För varje bild plockar jag ut samtliga kombinationer av tre cirklar. Finns det 66 cirklar blir det 45 760 möjliga kombinationer. För varje cirkelkombination kontrollerar jag:

• - Skillnaderna mellan cirklarnas vertikalläge (ska i absoluta mått vara snarlik)
  - Skillnaderna mellan cirklarnas horisontalläge (ska i absoluta mått vara snarlik)
  - Skillnaderna mellan cirklarnas radie (ska i absoluta mått vara snarlik)

För varje bild där jag endast kan finna en (1) uppsättning (3 cirklar) som är acceptabla, så poängsätter jag cirkeluppsättningen utifrån cirkeluppsättningens avvikelser från idealet. Idealet är här tre cirklar som ligger på en rät linje där:

• - samtliga cirklar har samma diameter
  - cirklarnas höjdpositionskillnader är 2 * cirkelradien
  - cirklarnas sidopositionsskillnader är 1/20 * cirkelradien

Alla mått tas här av naturliga skäl i antal pixlar.

Bilder där jag inte kan finna någon acceptabel uppsättning av tre cirklar kasseras.*
Bilder där jag identifierar mer än en (1) acceptabel uppsättning av tre cirklar kasseras.*

Av de bilder som återstår kasserar jag alla som har en poängsättning som understiger den högst funna.*

* I själva verket sparar jag aldrig några ”bilder”. Jag sparar bara listor med cirklarnas positioner och radier samt till dem hörande tröskelvärden. För övrigt så är en bild bara en stor matris fylld med numeriska värden.

För de bilder som återstår (alla har samma poäng) väljer jag ut den som har median-tröskel-värdet. Skal-etiketterna kommer nu att återfinnas inom bildens tre ”magiska” cirklar.

threshold_85_circles.jpg

När detta är gjort fastställs preliminära beskärningar. Dessa är att betrakta som relativt grovhuggna. Det viktiga här är att de alltid omsluter respektive skal-etikett-spets.

prelcrop.jpg

Jag bearbetar nu i tur och ordning de tre delbilderna. Jag börjar med att ta fram en minsta-omslutande-cirkel. Därefter beskär jag bilden på så sätt att jag tar bort en vertikal pixelrad på vänster sida. Jag tar ånyo fram en minsta-omslutande-cirkel. Jag upprepar detta tills jag inte får fram någon cirkel längre. Bilden har då blivit så smal att skal-etikett-spetsen inte längre finns med i bild (vid fastställt tröskelvärde). Den minsta-omslutande-cirkel från föregående bild kommer då att vara placerad på den eller de pixlar som utgör den yttersta skal-etikett-spetsen (vid det fastställda tröskelvärdet).

tagtops.jpg

Notera att man här faktiskt missar att exakt positionera spetsarna. Det beror på att det valda tröskelvärdet inte är optimalt för själva spetsarna. Det spelar ingen som helst roll, då detta är en grovkalibrering. Vi vill bara identifiera vilket område som är relevant att analysera för den slutliga positioneringen.

Utifrån positioneringen av skal-etikett-spetsarna beslutas om en slutlig beskärning.

finalcrop.jpg

Denna logik är mer komplex och betydligt omständligare än den som jobbade mot de två röda punkterna. Trots detta är den extremt mycket snabbare. Raspberry'n genomför nu grov- och finkalibrering på mellan 1,38 och 1,44 sekunder. Jag kan också konstatera att positionering av skal-etiketter och bom nu fungerar under alla ljusförhållanden (från sängkammarbelysning till fullt dagsljus). Dock kan problem uppstå vid kraftig punktbelysning från ett eller flera håll. Det kan då uppstå ofördelaktiga reflexer från vågens olika ytor. Det är nog omöjligt att hantera sådana ljusförhållanden på annat sätt än att bygga in vågen i en låda med belysning. Om ljuset bara är någorlunda diffust, så fungerar det dock utmärkt.

Jag har också strukturerat koden, så att de delar som är specifika för just min våg-modell är separerade. Därmed ska det vara ”enkelt” att komplettera med positioneringskod för andra balansvågar.

Det här var svettigt, men nu är resten enkelt! Hoppas jag inte tråkar ut er.

Mjukvaruutveckling 7 timmar.

[johaneriksson]

Detta är mest spännande tråden på länge

[andreasv]

Stabilt. Hade planer på nåt liknande men din approach är lite annan. Mycket intressant, bra jobbat.

[Öskar]

Det verkar som om de nyktrat till i öster. I vart fall de själar som hade hand om min display-försändelse.

[bild]

display_inkopplad.jpg

Det enda jag inte är på det klara med är LED-belysningen. Jag kunde inte mäta upp något motstånd mellan de två stift som går till bakgrundsbelysningen. Självklart följde det inte med någon dokumentation. Mina elektronikkunskaper är tämligen begränsade, men jag förstår att jag måste koppla ett motstånd mellan strömkällan (5v) och stiften (då det inte förefaller finnas något inbyggt). Nu hittade jag bara ett motstånd på 1000 Ohm. Enligt mina bristfälliga kunskaper skulle det vara långt mer än nödvändigt, men displayen är ändå väldigt ljusstark. Nu kostade ju displayen bara SEK 12,39 men leveranstiden förefaller ju vara avhängig av tillgången på sprit i mittens rike. Är inte sugen på att behöva vänta en gång till... Bör jag införskaffa större motstånd, eller är jag på säkra sidan? Någon som vet (spekulationer undanbedes)?

Det var i alla fall enkelt att koda för displayen. Nu hade jag redan innan byggt upp en dummy-display-klass (som skrev ut display-testerna på datorskärmen i brist på LCD-display). Det tog mindre än 30 minuter att konvertera koden för att passa LCD-displayen.

Display - hårdvara och mjukvara 1 timme.

Nu ska jag bygga upp en struktur för helhetslösningen för att få alla hård- och mjukvarudelar att arbeta tillsammans.

[Fält]

1kOhm låter väldigt mycket till LED belysningen på en LCD. Det är inte kontrasten (ofta pin3) du tänker på?

Belysningen är ofta pinne 15 och 16.

Jörgen

[Öskar]

1kOhm låter väldigt mycket till LED belysningen på en LCD. Det är inte kontrasten (ofta pin3) du tänker på?

Nix. Kontrasten (pin 3) har jag kopplat till jord/ground. Prövade även att koppla den till 3,3v, men då blev displayen helt oläslig. Pin 15 och 16 avser precis som du nämner LED-belysningen. Ättrig och otrevligt ljus ger den i alla fall. Skull naturligtvis valt en med grön belysning istället. Lätt att vara efterklok.

[Öskar]

Hittills har jag nästan uteslutande jobbat med att få "enskilda funktioner” att göra sitt ”isolerade arbete”. Nu jobbar jag på att få dessa komponenter att samarbeta. Faktiskt svårare än man kan tro! Fint väder gör arbetet långsammare.

Har tagit fram ett förenklat status- och transiteringsschema för helheten.

status_och_transitering.jpg

Fyrkantiga boxar är en status som programmet befinner sig i. Normal arbetsdrift representeras av de grå boxarna. Svara pilar är transiteringar (statusbyte) som sker automatiskt. Finns det flera svarta pilar ut från en status så följer programmet någon av dem. Programmet kan bara befinna sig i en status (vid varje godtycklig tidpunkt). Färgade pilar (ej svarta) initieras av knapptryckningar.

Vid normal arbetsdrift utför användaren två åtgärder:

• - trycker på den "blå" knappen för att starta laddning (efter att ha satt tillbaks krutkärlet på vågen)
  - lyfter bort krutkärlet från vågen (när laddningen är färdig, dvs status = Finished)

Alla statusar kan gå direkt till Error (har inte märkt ut de transiteringsmöjligheterna).

Jag gör ingen skillnad på att starta operativsystemet och att starta mjukvaran (startar man Raspberry'n så startar man också mjukvaran). Samma sak vid shutdown. Man kan inte stänga mjukvaran utan att också göra shutdown av operativet. Under utvecklingsarbetet startas och stängs dock programmet oberoende av operativsystemet.

Tankearbete (design) 3,5 timmar
Statusschema 0,5 timmar

[Öskar]

Kan rapportera följande:

Multitrådning
Applikationen är nu multi-trådad. Lite förenklat kan det förklaras med att olika delar av programmet jobbar asynkront (trådarna jobbar alltså parallellt och utan att behöva vänta på varandra). Lite som att ha flera program igång samtidigt på datorn. En del av programmet kan alltså kontinuerligt ”lyssna efter knapptryckningar” samtidigt som en annan del kör stegmotorn. Trådarna kan också kommunicera med varandra. Om knappen ”stop” detekteras, så skickas en signal till huvudprogrammet som i sin tur meddelar stegmotor-tråden att stegmotorn ska stoppas.

Stegmotor-objektet är ”semi-autonomt”. Så fort det är startat så är det som ett självspelande piano. Stegmotor-objektet startar en semi-autonom tråd som kör stegmotorn. När en laddning är klar så ”dödar” tråden sig själv för att spara på systemresurser. När nästa laddning påbörjas så startar stegmotor-objektet en ny semi-autonom tråd som ånyo självständigt kör stegmotorn i den hastighet som våg-objektet beslutar. Upplägget hindrar stegmotorn från att ”lagga” när programmet är upptaget med att analysera bilder och utföra beräkningar.

Mät- och beslutsvärden
Utifrån bommens uppmätta positioner och till dem hörande tidsstämplar beräknar jag;
- bommens hastighet (skalteckendistanser per sekund)
- bommens rörelseriktning (upp/ner)
- bommens acceleration (skalteckendistanser per sekundkvadrat)
Jag håller även reda på bommens senaste max- respektive minpunkt.
Jag gör en enkel prognos för bommens balanspunkt.
Jag beräknar vikt-avvikelse (antal grain) mot önskad laddvikt.
Jag fastställer även ett beam_stability_index (ett index för bommens ”rörlighet”). Om bommens rörelser inte är mätbara under de 12 senaste bilderna så sätts indexet till noll (0). Om bommen rört sig ”kraftigt” så blir indexet sex (6).

Beslutsalgoritm
Har tagit fram en pinsamt enkel beslutsalgoritmen för stegmotor-hastighet. Den använder bara bommens senast kända position och beam_stability_index som beslutsunderlag. Jag tycker inte att det är någon idé att påbörja jobbet med en avancerad beslutsalgoritm innan dispensen är up-and-running. Jag måste helt enkelt kunna mata krut både fort och långsamt först. Med all säkerhet måste jag byta stegmotor och reglerkort för att få upp matningshastigheten. Troligen måste jag också mickla med tricklern. Beslutsalgoritmen måste samverka med och anpassas till hårdvaran. Det ska bli kul när jag kommit så långt . . .

Konfigurationsfil
Jag har en lyft ut parametervärden som påverkar dispensens karaktäristika i en separat konfigurationsfil (t ex vilka olika hastigheter stegmotorn har). Det gör det enklare att ”mixtra” med programmet utan att behöva programmera.

Logging
I konfigurationsfilen kan jag slå på (och av) logging. Då skrivs en loggfil för varje gång dispensern "körs". Alltså en fil för hela livscykeln (från boot till shutdown). Loggen registrerar alla knapptryckningar och statusförändringar. Samtliga kalibreringsvärden bokförs. För varje laddning skrivs också en rad per bild som analyserats. Bl a skrivs bommens position, bommens hastighet, bommens acceleration, bommens rörelseriktning, bommens senast kända min- och maxpunkt, bommens beräknade balanspunkt, bommens stabilitetsindex, beslut om stegmotorhasighet, bildens tidsstämpel. Varje bild tilldelas också ett unikt ID-nummmer.

Videoinspelning
I konfigurationsfilen kan jag även slå på videoinspelning. Då sparas en video för varje laddning. Varje bild/frame i videon får sina beräknade skal-etikett-positioner samt sin bom-position utmärkt med vertikala linjer (se bilder tidigare inlägg). Varje bild/frame förses även med sitt unika ID-nummer (skrivs ut i nedre högra hörnet). Detta gör det möjligt att i efterhand koppla ihop varje enskild bild med dess loggade datavärden och dito fattade beslut. Därmed kan man efterhandsanalysera de beslut som mjukvaran tog. Det blir ett bra underlag för optimering av alla beslutsalgoritmer.

Hårdvarudetektering och dummy-moduler
Eftersom jag utvecklar på PC'n har det på sistone varit mycket jobb med att ideligen flytta utfört jobb till Raspberryn för att ”provköra”. Mycket irriterande och tidskrävande! Nödvändigt kan man tro, då helhetslösningen är hårdvaruspecifik för Raspberry'n (till exempel kommunikation mot GPIO-pins som inte finns i en vanlig PC). Jag håller inte heller på att flytta USB-kameran fram och tillbaka. Jag har löst det så här;

I början på huvudprogrammet tar jag reda på vilket operativsystem mjukvaran körs på. Om det är Raspbian så är allt väl för då är hårdvaran Raspberry'n. Men om operativet är något annat, då är också hårdvaran ”annan”. Utifrån den kännedomen väljer huvudprogrammet vilka program-moduler som ska laddas. För Rasberry'n laddas till exempel en modul som heter mdlCamera.py som hanterar webbkameran. Men på PC laddas istället modulen mdlCameraDUMMY.py. Dummy-modulen har precis samma funktioner, metoder och gränssnitt som sin systermodul men är hårdvaruoberoende. Dummy'n för kameran laddar en förinspelad video och skickar de bilderna till huvudprogrammet (såsom vore det en live streaming). Huvudprogrammet har ingen aning om att det ”blir lurat”. På det sättet kan jag provköra lejonparten av all kod på PC'n. Dummy'n för stegmotorn skriver bara ut mottagen information på skärmen. Självklart kan jag inte kontrollera om stegmotorn faktiskt roterar, men jag kan köra helhetslösningen på PC'n. Därmed kan jag testa stora delar av logiken utan att slösa bort tid på ”programinstallationer”. Dummyn för de återfjädrande tryckknapparna ”fångar” istället ”tangentbordstryckningar”.

Kanske låter löjligt, men faktum är att dessa dummies sparar mig mycket tid och frustration.

Positionering av bom och skala
Jag har nu utsatt skal- och bompositionering för diverse prövningar. Jag kan konstatera att jag utan problem kan läsa av vågen under alla tänkbara normalt förekommande situationer. Om jag till exempel ställer in laddvikten på 40 grain och släpper i 40 grain på en gång, så börjar bommen gunga kraftigt. Trots det positioneras bommen korrekt på samtliga bilder. Verifierat genom videoinspelning.


Precis som när man bygger något mekaniskt, så är det när man försöker plocka ihop enskilda delar till en helhet, som man identifierar de största tankevurporna. På schemat står nu integration och rättning av större och mindre fadäser.

Studier multitrådning 2 timmar
Mjukvaruutveckling 15 timmar

Ledsen för långt inlägg utan bilder.

[Ulrik]

Grymt bra jobbat, jag är imponerad över resultatet och slutsatserna.
Faktum är att mycket av jobbet som programmerare är att strukturera och jobba med att förenkla saker som deployment (flytta saker mellan utvecklingsmiljöer till driftsmiljöer) konfiguerering och tester och loggning. Speciellt i inbäddade system så kan det vara svårt att förstå vad som händer när systemet körs så då är en bra loggning avgörande för att felsöka och rätta fel.
Nu får du gå vidare med nya projekt

[Öskar]

Man tackar för beröm. Jag imponerar även på mig själv. Faktum är dock att min kod har en hel del brister. Därtill finns det säkert mängder med ännu oupptäckta brister .

När jag tittar på den kod jag skrev i början, så tycker jag den är infantil . Jag antar att det betyder att jag utvecklats .

Grymt kul med programmering i alla fall. Kommer definitivt att bli en och annan mörk vinterkväll framför skärmen. Naturligtvis extra stimulerade när man samtidigt åstadkommer något användbart. Programmering sätter verkligen hjärnan på prov.

Bra väder i helgen gör att projektet får vila.

[Öskar]

Kort uppdatering

Har testat, rättat fel och gjort lite förbättringar. De flesta fel och förbättringar har varit lätta att fixa. Några enstaka har varit mer omfattande på så sätt att en rättning lett till nya fel. De svårrättade felen beror samtliga på dåligt förarbete (ej tänkt igenom helheten före programmering).

Har också rättat en pinsam tankevurpa avseende videoinspelningen (den för optimering av beslutsalgoritmer). I videon la jag på vertikala linjer för att visa positionering av skaltecknen och bom. Smart tänkte jag – då blir det lätt att visuellt avsyna videon/laddningen. Men... då blir också videon besudlad och visar inte vad ”systemet faktiskt såg”. Om jag istället avstår från att ”manipulera” videon, så kan jag ju köra den genom programmet (via min kamera-dummy-modul) om och om igen. Jag kan då efter ändring i programkoden snabbt kontrollera vilken effekt det hade på t ex stegmotorhastigheten. Förvisso kan jag inte se de exakta effekterna (om andra beslut hade fattats, så hade ju videon/laddningen också fått ett annan förlopp), men jag kan snabbt få en god uppfattning om konsekvenserna av en ändring. Den uppfattningen kan jag dessutom få utan att faktiskt använda själva dispensern (räcker med PC'n). Tog mindre är 2 minuter att rätta.

Jag hoppas att inom kort faktiskt provköra dispensern på riktigt. Hittills har jag bara torrsimmat genom att manuellt kasta i diverse föremål i vågskålen.

Test, rättningar och förbättringar av mjukvara 3 timmar

Lärdom nummer 6: Ordentligt förarbete lönar sig i längden.

[Öskar]

BSIRAD förlorar oskulden

Varning: har du svårt för skrytsamma inlägg - sluta läs nu! Idag är jag är så impregnerad med självgodhet, att det rinner ut ur öronen. Håll till godo . . .

Idag gjorde jag det*!

*det:

• - fyllde på krut (Vihtavuori n32c) i tricklern
  - nollade balansvågen
  - ställde in laddvikten (9,0gr)
  - slog på strömmen

Inget tangentbord, ingen datorskärm, bara BSIRAD, jag och en flaska Vihtavuori!

BSIRAD_complete.JPG

Meddelanden rullar förbi på BSIRAD's display:

display_boot.jpg

och:

display_calibrating.jpg

48 sekunder efter att strömmen slagits på meddelar BSIRAD's display:

display_idle.jpg

Känslan är exakt som när jag var 14 år och storasyrrans bästa kompis frågade mig om jag ville . . .
. . . okej . . . kanske inte exakt, men i det häradet.

Med darrande hand trycker jag på klit . . . knappen . . . laddningsknappen . . . reaktionen låter inte vänta på sig. Stegmotorn drar omedelbart igång med full fart. Matningsröret är tomt och det tar några sekunder innan krutet börjar droppa ner i vågskålen. Displayen visar:

display_loading_beam_resting.JPG

Efter 23 sekunder efter att krutet börjar droppa ner i krutkärlet lyfter bommen. Stegmotorn tvärstannar direkt. Efter mindre än en sekund drar den igång igen, men med något lägre varvtal. Displayen visar:

display_loading_beam_balancing.JPG

Man kan alltså avläsa följande:
- att laddning pågår
- hur lång tid som förlöpt
- avvikelse i grain mot inställd laddvikt (endast om bommen lyft)
- avvikelse mellan bom och skala i antal pixlar

Vartefter bommen närmar sig den mellersta skal-etiketten, så minskar varvtalet. Strax före korrekt laddvikt går dispensern över i ”trickle-mode”, dvs matningsröret rycker fram stegvis (1/2048-dels varv var 1/10-dels sekund). Stegmotorn stannar när bommen befinner sig på exakt samma pixelhöjd som den mittersta skal-etiketten. Efter ytterligare 1,5 sekunder fattar BSIRAD beslutet att laddningen är färdig. Displayen visar:

display_finished_1.JPG

Jag studerar arangemanget under en halv minut. Inget händer. Display-texten är oförändrad. Jag blåser mycket lätt på bommen, som rör sig knappt märkbart. Displayen slår om till:

display_beam_unstable.JPG

Efter några sekunder går displayen tillbaks till "Finished 54 sek, 0.00 gr 0 pix".

Medelst pincett släpper jag på två (2) krutkorn till. Displayen slår om till:

display_finished_1_provoked_1.JPG

Jag släpper på ytterligare några krutkorn och displayen växlar mellan lite värden för att till slut visa

display_finished_1_provoked_2.JPG

Fortsättning i nästa inlägg (pga max 10 bilagor per inlägg) . . .

[Öskar]

fortsättning . . .

Med pincetten plockar jag försiktigt bort några krutkorn. När bommen stabiliserats visar displayen:

display_finished_1_provoked_3.JPG

Jag trycker på laddningsknappen och stegmotorn börjar trickla direkt. När BSIRAD befinner sig i status Finished, så fortsätter kameran och laddningsalgoritmen att jobba (stegmotorn dock spärrad). Det gör att det finns ”full” historik, fullständiga analyser och beslutsvärden färdiga. Därmed kan BSIRAD omedelbart påbörja (fortsätta) laddning när man trycker ner laddningsknappen.

Det tar 8 sekunder att fylla upp de saknade 0,04 grain'en:

display_finished_2.JPG

Jag lyfter bort krutskålen, och displayen slår direkt om till ”BSIRAD is ready to load...”. Innan jag hunnit slå tillbaks det uppvägda krutet i tricklerbehållaren har alltså BSIRAD omkalibrerat sig (i händelse kamera eller våg är tillstött) och är nu redo att påbörja nästa laddning.

Jag sätter tillbaks krutskålen och trycker ånyo på laddknappen. Stegmotorn drar igång direkt. Jag sticker ner ett papper mellan kamera och våg. Stegmotorn tvärstannar. Displayen visar:

display_warning.JPG

Jag tar bort pappret. Displayen slår direkt tillbaks till ”loading”. Det tar någon sekund innan stegmotorn drar igång (systemet behöver lite historik för att fatta beslut). Jag sätter tillbaks pappret. Samma reaktion. Jag tar bort pappret och låter BSIRAD jobba färdigt. Hon stannar på 0.01 grains avvikelse.

display_finished_3.JPG

Jag trycker på laddningsknappen utan att först ta bort krutkärlet. Stegmotorn rör inte en fena. Displayen blinkar till "Loading 0 sec, 0.01 gr 0 pix", för att direkt slå om till "Finished 0 sec, 0.01 gr 0 pix".

Tar bort och tömmer krutkärlet. Kör ytterligare en laddning. Denna gång utan att störa BSIRAD.

display_finished_4.JPG

Femte laddningen går inte lika bra:

display_finished_5.JPG

Overcharge-gränsen sätts i den separata konfigurationsfilen och värdet är för närvarande satt till 0.04 grains.

Jag tömmer krutkärlet och kör igen. Mitt i laddningen trycker jag på stopp-knappen. Stegmotorn tvärstannar och displayen visar ”BSIRAD is ready to load...”. Jag trycker på laddningskanppen. Laddningen startar upp igen.

Jag kör ett 20 laddningar och de utfaller på följande sätt:

• 10 st slutar på 0.00 grain i avvikelse
  4 st slutar på 0.01 grain i avvikelse
  2 st slutar på 0.02 grain i avvikelse
  1 st slutar på 0.03 grain i avvikelse
  1 st slutar på 0.05 grain i avvikelse
  2 st slutar på 0.06 grain i avvikelse

Underladdning förekommer inte alls. En snabb okulärbesiktning av tricklern medans den jobbar påvisar problemet. När matningsröret roterar följer krutet med röret upp för att därefter ”åka kana i nerförsbacken”. Det gör att flödet blir intermittent. Under en kort tidsperiod kommer inget krut alls. Därefter kommer flera korn i snabb följd (ibland samtidigt).

Trots det mediokra utfallet är jag dj-----t stolt. Okej, hon är ful och uppvisar undermålig prestanda . . . men jag älskar henne . . . och det är äkta kärlek! Jag är gammal och grinig, men hon är ung och formbar. Jag känner på mig att vi kommer att bli lyckliga tillsammans!

Vihtavuori n32c är ett ganska avvikande krut. Det är bulkigt; ett krutkorn väger i genomsnitt 0,0136 grain. Vikten mellan vågen skal-etiketter är 0,64 grain. Det blir 47 krutkorn mellan nedre och mellersta skal-etiketten. I logg-filen kunde jag i efterhand konstatera att antalet dito pixlar var 66. Således mindre än 0,01 grain per pixel eller 1,4 pixlar per krutkorn. Matningshastigheten vid högsta rotationshastighet är 0,37 grain/sekund. Jag provade VV n32c först, eftersom jag använder det krutet ganska mycket och den laddningen är känslig för avvikelser.

Nästa krut ut är Norma 202 (runt 43 grain), men då ska jag passa på att föra in det uppvägda krutet i hylsor samtidigt. Några synergieffekter måste jag klämma ut ur detta experiment.

Slutsatser:

• Det behövs en snabbare stegmotor.
  Matningsrörets diameter måste minskas, eller så måste ytan på rörets insida ha en lägre friktion.
  Det är ingen idé att börja optimera beslutsalgoritmerna förrän en snabbare stegmotor är inkopplad.
  Det är ingen idé att börja experimentera med tricklern förrän en snabbare stegmotor är inkopplad.

Jag är så dj---a exalterad! Jag återkommer med vidare rapport när jag nyktrat till ur mitt euforiska tillstånd.

Praktisk test 2 timmar

[redtop]

Grymt jobbat! Verkligen imponerande!

När jag läser hur den funkar så låter det som om man skulle kunna göra en "grovfyllning" själv för att det inte ska ta så lång tid att ladda.
Säg t.ex att man vill väga upp 44gr. Om man tar ett lagom mått (kryddmått eller nåt sånt) och skopar i så man får säg 35-40gr och låter tricklern göra resten så vinner man kanske en hel del tid, och behöver inte kraftigare/snabbare stegmotor.

Bara en idé!

[Öskar]

När jag läser hur den funkar så låter det som om man skulle kunna göra en "grovfyllning" själv för att det inte ska ta så lång tid att ladda.

Tanken om manuell ”förladdning” har slagit mig. Jag tror dock att det går att åstadkomma en fungerande lösning som fixar hela laddningen. Tänk tanken att du fyller på det laddade krutet i hylsan, sätter tillbaks krutkärlet och trycker på en knapp. När du är färdig med kulsättningen så är nästa laddning färdig. Kanske en utopi . . .

Kommer först att prova hur andra krutsorter (Norma 200 och 202) beter sig i nuvarande lösning. Därefter kommer jag troligen att göra en ny trickler. Sannolikt med ett mindre matningsrör. Blir mer och mer övertygad om att matningsröret är för stort. Först därefter kommer jag fundera på stegmotor och stegmotordrivare.

Någon som har en trickler och kan tänka sig att mäta innerdiametern på matningsröret?

[redtop]

Den här antar jag att du har koll på?

http://www.autotrickler.com/" onclick="window.open(this.href);return false;

[Fält]

Gratulerar till det lyckade provet!
Det är en underbar känsla när man kämpat sig igenom ett projekt helt själv!

Kan du tänka dig en variant där man kombinerar en vibrationstrickler som den som används med Autotricker med en enkel krutdispenser som ger en viss mängd krut per varv?

Jörgen