Arduino - ta medelvärde från beräkning, inte sensordata

[sodjan]

Ja, float är *mycket* "tyngre" att hantera för den typ av
processorer som sitter i t.ex. en Arduino. Den kan handla
om 100-1000 gånger mer kraft för att göra beräkningar.

Jag vet inte hur formatet ser ut som du får tillbaka från sensorerna,
men det vore underligt om det inte skulle gå att hantera med ett
par integers. Om man behöver "decimler" så skalar man bara värdet
t.ex. 10 gånger för 1 decimal eller 100 gånger för 2 decimlar o.s.v.

> Det fungerade inte för att den helt enkelt inte printade ut IsSafe efter att 15 värden tagits in.

Men du vet alltså inte varför? Min gissning är att du får något over/under flow
som gör att något internt värde i beräkningen avrundas till 0 eller liknande.
Lösningen är att bryta ner beräkningen i individuella steg och printa
alla delresultat för att se var det går snett.

Alltså istället för:

avg_delta_celsius= (avg_delta_celsius*14.0+delta_celsius)/15.0;

Så gör du något i stil med:

tmp1 = avg_delta_celsius*14.0;
tmp2 = tmp1 + delta_celsius;
tmp3 = tmp2 / 15.0;
avg_delta_celsius = tmp3;

och kollar varje delresultat för eventuella fel. Bara helt vanlig felsökning...

[Corpze]

Det verkar som att min float fungerade, dock behöver jag inte ta 300 värde utan kanske 30 eftersom min sensor har 90 graders FOV samt gör en intern beräkning av medelvärdet.

Skall testa mer innan jag provat med en integer också.

[mounte]

Ett knep som jag nyttjat ibland för att få en stabil förgrund-bakgrundssegmentering inom bildanalys på videosekvenser är att fuska till sig en median-bild istället för medelvärdes-bild.
Problemet med att skatta medianen för en okänt lång sekvens är ju att veta vad som är "mitten" på sekvensen.
Så till knepet:
QAD-implementation, icke testad (Quick And Dirty)

Kod: Markera allt

int sensor = 0;
int median = 0;

for(;;)
{
  sensor = read_sensor();
  if(sensor > median)
    median++;
  else if(sensor < median)
    median--;

  do_stuff(median);
}

det finns en rad fördelar och några nackdelar med denna metod.
Fördelar är att stora sensorutslag eller brus påverkar resultatet minimalt.
Men konvergensen kan vara lite långsam, kan därför vara vettigt att bootstrapa det initiella värdet med medelvärdet av ett antal samples för att hamna lite närmre.
Korrekt implementerad så går det väldigt fort och kräver endast heltalsoperationer. Beroende på arkitektur så kan sanningsvärdet på sensor > median användas listigare så att man slipper branch-operationer i for-loopen.

[lillahuset]

Konvergensen (startvärdet) ställer i min erfarenhet nästan alltid till problem. Som jag skrev tidigare, ju smartare man försöker vara desto större är risken att det går åt helvete.

[bit96]

Kanske kan du utgå från "förfluten tid" istället.
Ett enstaka för högt värde, alltså motsvarande under en sekund, bör rimligtvis inte betyda att ett moln blixtsnabb kommer fram och börjar regna.

T.ex. kan du hålla reda på de 30 sista värdena (alltså en halv minut) och om minst 20 har för höga värden så är regn på gång.
Exakta värden får man prova fram med erfarenhet.

Detta kan göras med medlevärde/lågpass-filtrering med det ger alltid ett litet fel samt besvärliga insvängningsförlopp.
En vektor, cikulär kö eller liknande där du räknar på exakta värden är nog mer pålitlig och dessutom kan du se till att 30 värden läses in innan beräkning påbörjas.

Hmm, påminner kanske lite om Sodjans förslag med upp- och ner-räknare?

[Corpze]

Lyckades bränna IR sensorn när allt skulle monteras i en vädertätad låda och provköras i skarpt läge, men de tester hittills visar på bra mätvärden och en "lagom" snabb respons på förbipasserande moln, är det molnfritt är tempdiffen mark-moln mer är 21 grader.
Drivrutinen till datorn fick jag hjälp med av en kille i Philadelphia och fungerar fint med automatiseringsprogrammet till observatoriet