Automatisk krutdispenser

[Katjing]

Har lyckats strula till det ordentligt! Jag har gjort flera (många) rättningar/ändringar/förbättringar utan att testa av emellan. När jag väl provkörde på PC fungerade det inte alls. Mängder med fel. Så fort ett fel var rättat få föll BSIRAD på nästa. När jag efter mycket jobb lyckades få koden att rulla på PC'n, så gick jag över till Rasberry'n. Då började helvetet om . . . Har inte lyckats få BSIRAD up-and-running ännu. Jag är i färd med att beta av fel efter fel. Varje gång är jag övertygad om att just det felet är det sista . . . men icke! Det är därtill betydligt svårare/långsammare att felsöka/avlusa på den riktiga hårdvaran. Som grädde på moset så kraschar BSIRAD helt ibland. Eller så slutar hon att respondera (typiskt sett med stegmotorn i full spätta).

Hade jag vetat hur mycket tid felsökning och rättning skulle ta, så hade jag backat tillbaks till föregående version. Därefter hade jag gjort om ändringarna en och en med test emellan.

Just nu är det surt!

Felrättningar 12 timmar

Det är kul att följa hur du går på samma minor som alla andra som lär sig att programmera. Se det som en del av lärandet bara. Nästa gång går det bättre.

Jag tänkte föreslå användandet av ett versionshanteringsprogram, t.ex. Git, tidigare. Använder du något sådant?

[Öskar]

Har lyckats strula till det ordentligt! Jag har gjort flera (många) rättningar/ändringar/förbättringar utan att testa av emellan. När jag väl provkörde på PC fungerade det inte alls. Mängder med fel. Så fort ett fel var rättat få föll BSIRAD på nästa. När jag efter mycket jobb lyckades få koden att rulla på PC'n, så gick jag över till Rasberry'n. Då började helvetet om . . . Har inte lyckats få BSIRAD up-and-running ännu. Jag är i färd med att beta av fel efter fel. Varje gång är jag övertygad om att just det felet är det sista . . . men icke! Det är därtill betydligt svårare/långsammare att felsöka/avlusa på den riktiga hårdvaran. Som grädde på moset så kraschar BSIRAD helt ibland. Eller så slutar hon att respondera (typiskt sett med stegmotorn i full spätta).

Hade jag vetat hur mycket tid felsökning och rättning skulle ta, så hade jag backat tillbaks till föregående version. Därefter hade jag gjort om ändringarna en och en med test emellan.

Just nu är det surt!

Felrättningar 12 timmar

Det är kul att följa hur du går på samma minor som alla andra som lär sig att programmera. Se det som en del av lärandet bara. Nästa gång går det bättre.

Jag tänkte föreslå användandet av ett versionshanteringsprogram, t.ex. Git, tidigare. Använder du något sådant?

Nix, jag använder inget versionshanteringsverktyg. Har varit tillräckligt mycket nytt att sätta sig in i. Har försökt hålla ner mängden nya saker att lära mig.

Har kör med egenhändig manuell versionshantering. Vare ändring får en ny mapp med sitt versionsnummer. Jag kopierar samtliga programfiler till mappen och ändrar i den eller de programfiler som berörs. Samtidigt för jag en ganska omfattande logg över alla ändringar. Jag noterar syfte med ändring, vilka programfiler/funktioner/klasser/metoder som berörs. Därefter blir det ytterligare en version för testning/rättning.

Den här gången fuskade jag. Jag hade en lista med ca 50 stycken "små skitsaker" som jag stört mig på. Jag gjorde alla "på fri hand" och i ett svep (uppdelat på 8 versioner) utan att testa av emellan. Började väl bli kaxig!

Tack för tipset om versionshanteringsverktyg. Tror dock att jag tillsvidare håller mig till mina manuella rutiner. Bara jag följer dem, så fungerar de. I min ålder måste man prioritera när det kommer till att lära sig nya verktyg.

[J. Andersson]

Herregud! Hur mycket tid har du ägnat åt projektet vid det här laget?

Imponerande tålamod.

[Öskar]

237,5 timmar + 387,07 kronor . . . men jag har haft fan så kul . . . och så har jag lärt mig att programmera . . .

[Öskar]

Avrapportering

Jag har nu rättat till naturens misstag. BSIRAD är nu ”up and running”. Därtill med betydligt högre prestanda än innan. Faktum är att jag fått lägga in lite konstgjorda pauser på utvalda ställen där koden ”går för fort”. Kalibreringen tex. Det bara blinkar till på displayen. Har lagt in en paus på en halv sekund när kalibreringen är färdig. På det sättet hinner man läsa av displayen.

Det är en stor lättnad att vara på banan igen. Närmast på agendan står nu dokumentation samt utveckling av ny beslutsalgoritm. De sistnämnda ser jag fram emot.

Rättningar (av rättningar) 2 timmar

[Karre]

Då borde det vara läge för film?

[Öskar]

Då borde det vara läge för film?

Jag hade gärna laddat upp några små videos här på Robsoft, men det är spärrat (vilket jag har full förståelse för).

[Karre]

Då borde det vara läge för film?

Jag hade gärna laddat upp några små videos här på Robsoft, men det är spärrat (vilket jag har full förståelse för).

Vad är det för fel på youtube?

[Öskar]

Vad är det för fel på youtube?

användarvillkoren

[Öskar]

Krutmatning/beslutsalgoritm

Jobbar just nu på en ny beslutsalgoritm/beslutslogik.

Det grundläggande problemet med den nuvarande matningen är att den jobbar intermitent. Först matar den. Då börjar bommen gunga, vilket får till följd att matningen pausar. När bommen lugnat ner sig återstartar matningen, vilket får bommen att börja gunga . . . Ju närmare laddvikten jag kommer, desto mindre bomrörelser accepteras.

Jag håller på att utforma en beslutsalgoritm med ”dynamisk krutmatning”. Den bygger på att jag kontinuerligt gör en prognos över bommens balansposition. Avståndet mellan den prognostiserade balanspositionen och målpositionen sätter en grundhastighet. Ju större avstånd desto högre grundhastighet. Grundhastigheten justeras därefter utifrån olika olika mätvärden:

• Om bommen är på väg uppåt så minskas rotationshastigheten med 20%. Om den är på väg nedåt så ökar rotationshastigheten med 20%. Detta ger i genomsnitt samma matningshastighet men hjälper till att dämpa bommens rörelse.
  
• Om bommens svängning är kraftig så minskas också matningshastigheten. Ju mindre avståndet är mellan den prognostiserade balanspunkten och målpositionen, desto kraftigare ”straff”. Straffet står också i proportion till hur kraftig bommens rörelse är.

Jag tänker mig att matningen ska ha sex (6) grundlägen:

1) Bommen har inte lyft och tidsgränsen för bulkload är ej uppnådd:
Absolut högsta matningshastighet (till följd av latenser i systemet leder denna matningshastighet till överladdning om bommen lyfter).
stegmotorhastighet = bulk_load_speed

2) Bommen har inte lyft men tidsgränsen för bulkload är uppnådd:
Högsta möjliga matningshastighet utan risk för överladdning.
Stegmotorhastighet = high_load_speed

3) Bommen har lyft men har ännu ej vänt nedåt (ingen maxpunkt finns):
Bommen är fortfarande på väg uppåt. Bommens balanspunkt kan ej prognostiseras. Laddningen pausas.
stegmotorhastighet = 0

4) Bommen har lyft, maxpunkt finns, bommens beräknade balanspunkt understiger positionen för ”tricklemode”:
Matningshastighet bestäms av en kontinuerlig funktion vars variabler är:
- bommens prognostiserade balanspunkt
- bommens rörelseriktning (upp/ner)
- bommens hastighet och acceleration
- differensen mellan bommens senaste min- och maxpunkt
stegmotorhastighet = variabel (roterande), successivt minskande

5) Bommens beräknade balanspunkt överstiger positionen för ”tricklemode”, bommens faktiska position understiger målpositionen:
Här upphör användandet av bommens beräknade balanspunkt. Istället tillämpas bommens faktiska position. Vidare så går krutmatningen över från rotationsmatning till vibrationsmatning (se tidigare inlägg). Även detta moment regleras med en kontinuerlig funktion. Vibrationshastigheten regleras steglöst beroende på bommens avstånd till målpositionen samt bommens rörelsehastighet. Endast mycket små och ”mjuka” bomrörelser accepteras (allt annat medför att krutmatningen pausas tills bommen är nästintill helt stilla). Ju närmare målvikten, desto lägre vibrationshastighet och snävare toleranser med avseende på tillåtna bomrörelser.
stegmotorhastighet = variabel (vibrerande), successivt minskande

5) Bommens beräknade balanspunkt överstiger positionen för ”tricklemode”, bommens faktiska position är vid eller överstiger målpositionen:
Matningen pausar. Är bommen stillastånde tillräckligt länge så är laddningen klar.
Stegmotorhastighet = 0

Jag hoppas med detta förfarande både kunna snabba upp laddcykeln och öka precisionen. Metoden möjliggör en mer kontinuerlig krutmatning, då systemet inte behöver invänta att bommen stabiliseras för att fatta beslut. Grundtanken är att om laddningen är ”uppenbart långt ifrån färdig” så behöver beslut om matningshastighet inte fattas med någon större noggrannhet. Ju närmare ”målvikten” laddningen kommer, desto noggrannare/försiktigare måste matningen göras. En annan viktig del är att krutmatningen användas för att dämpa bommens rörelser.

Rent mjukvarumässigt så kommer den här ändringen att vara relativt komplicerad. Den berör flera klasser/komponenter och ändrar dessutom en del grundprinciper. Bland annat har stegmotorklassen inte längre 6 fasta rotationshastigheter utan istället en rotations-grundhastighet som kan ”justeras steglöst” samt en dito vibrations-grundhastighet. Därmed kan inte stegmotorklassen hämta de s.k. paustiderna från konfigurationsfilen. Istället fattar våg-objektet beslut om matningen (stop, paus, rotation inkl varv/minut, vibration inkl motsvarande varv/minut). Utifrån de besluten måste stegmotor-objektet själv kontinuerligt beräkna tillämpliga paustider. Med paustid avses här de de tidsintervall som stegmotorn är "stillastående i en fix position" (se tidigare inlägg).

Tankeverksamhet 2 timmar

[sevehem]

Man kan undra när du är nöjd men jag tror att detta kommer bli en fullkomligt fantastisk pryl som säkerligen piskar chargemaster och andra varianter på fingrarna. En filmfil nästa gång nya koden funkar kanske kan delas via en öppen dropbox eller liknande? Inte för att man kan klaga på din dokumentation och hur väl du delar med dig men detta är ju det intressantaste projektet på forumet på lång tid så man är ju nyfiken som sjutton.

[Wikarn]

Kan du verkligen få krutkorn så snabbt ur röret till vågskålen att de dämpar bommens rörelse? I så fall föreställer jag mig att du skulle kunna fylla vågskålen svinfort om du accepterade avvikelser på till exempel +-0,2 grain. (Vilket jag dock förstått att du inte har för avsikt att göra.) Jag skulle också väldigt gärna se en video och har inget emot dropbox. Om du vill skulle jag även kunna tänka mig att ladda upp videon på min youtubekanal (men du kanske inte vill stödja youtube alls).

[Öskar]

Kan du verkligen få krutkorn så snabbt ur röret till vågskålen att de dämpar bommens rörelse?

Det krävs väldig lite för att bromsa bommen (en bråkdel av max flödet). Samtidigt krävs det lika lite för att sätta bommen i gungning. Att bromsa bommen kommer inte att vara några som helst problem, tvärtom kommer utmaningen vara att styra flödet så att det inte förorsakar så mycket gungning att flödet måste begränsas (pga att den prognostiserade balanspunkten blir osäker). Jag måste alltså hålla upp flödet utan att samma flöde forcerar fram en matningsbegränsning. Därav tanken med den dynamiska/adaptiva matningen.

I dagsläget är det slutfyllningen (från det att bommen lyft) som tar tid i anspråk. Att fylla tills bommen lyfter går mycket fort. Jag kan med lätthet mata 2 gr/sek.

[Öskar]

Jag noterar att det finns önskemål om rörlig bild. Ska se om det går att lösa på något smidigt sätt. Det jag har i dagsläget är några taffliga sekvenser med den gamla hårdvaran (gamla stegmotorn/tricklern/displayen). Inget som ä värt att göra sig något besvär för!

Ska se om jag kan fixa några ”fräscha” videos. Allt tar dock tid och videoproduktion står inte längst upp på agendan just nu.

men du kanske inte vill stödja youtube alls

Det är korrekt att jag hyser viss aversion mot Google-konglomeratet (vilket youtube är en del av).

[dilaiic]

Läste lite för fort och trodde först att du kallade projektet BRISAD.

[Öskar]

Läste lite för fort och trodde först att du kallade projektet BRISAD.

BRISAD hade helt klart också varit ett bra namn. Nu blev det BSIRAD.

[Öskar]

Avrapportering

Den nya beslutsalgoritmen är nu implementerad och avlusad, men ännu praktiskt oprövad. Jag har endast provkört den i PC'n medelst förinspelad video. Förändringen är dock så omfattande att det inte går att dra några slutsatser av en sådan simulering. Jag påräknar ju att den nya beslutslogiken kommer att väsentligt förändra krutmatningsförloppet.

Jag förmodar därtill att kalibreringen av denna nya beslutslogik kommer att kräva en ansenlig arbetsinsats.

Arbetet med denna ändring var lättare och gick snabbare än jag föreställt mig.

Programmering och test 3 timmar

[sevehem]

Avrapportering

Den nya beslutsalgoritmen är nu implementerad och avlusad, men ännu praktiskt oprövad. Jag har endast provkört den i PC'n medelst förinspelad video. Förändringen är dock så omfattande att det inte går att dra några slutsatser av en sådan simulering. Jag påräknar ju att den nya beslutslogiken kommer att väsentligt förändra krutmatningsförloppet.

Jag förmodar därtill att kalibreringen av denna nya beslutslogik kommer att kräva en ansenlig arbetsinsats.

Arbetet med denna ändring var lättare och gick snabbare än jag föreställt mig.

Programmering och test 3 timmar

Du börjar väl bli varm i kläderna! Det skall bli spännande att se hur mycket fortare det kommer gå.

[Katjing]

Jag undrar om du inte skulle vara betjänt av att estimera tillståndet med hjälp av ett partikelfilter och sedan kontrollera matningen med någon lämplig algoritm från reglerteknikens värld. Själv har jag i princip bara använt mig av PID, men jag tror inte att det passar sig här, så jag kan inte rekommendera någon så här på rak arm.

[Öskar]

Jag undrar om du inte skulle vara betjänt av att estimera tillståndet med hjälp av ett partikelfilter och sedan kontrollera matningen med någon lämplig algoritm från reglerteknikens värld.

"algoritm från reglerteknikens värld" förstår jag. Men det där med att "estimera tillståndet med hjälp av ett partikelfilter" tarvar för ett förtydligande. Jag tror att jag kommer att lägga lite krut på min hemmasnickrade algoritm innan jag letar vidare.

Själv har jag i princip bara använt mig av PID, men jag tror inte att det passar sig här

Jag är ingen expert på PID, men den typen av reglering passar väl primärt system med både in- och utflöde. Till exempel att hålla en balja med vatten vid en konstant temperatur (ett elpatron värmer samtidig som det förekommer värmeläckage). PID används väl därtill främst för kontinuerliga regleringar. En laddning är ju en ändlig process. Jag tror inte heller på PID.