traject berekenen

[arie]

Alternatief: gebruik de formules voor de eenparig versnelde beweging,
zie bijvoorbeeld http://nl.wikipedia.org/wiki/Eenparig_v ... e_beweging.
Je hebt dan in het begintraject een geleidelijke toename van de snelheid,
en na het stuk met constante snelheid laat je de snelheid geleidelijk afnemen.

Voorbeeld:
Kies voor dit voorbeeld de volgende waarden:
- de totale afstand waarover de camera zich moet verplaatsen (T') = 650 mm
- de afstand waarover geaccelereerd moet worden tot de maximale snelheid/positie.. u' (ramp up) = 100 mm
- de afstand waarover gedecelereerd moet worden tot in T' d'(ramp down) (de tussenliggende afstand bestaat dus uit constante intervallen) = 150 mm
- parameters om het totaal aantal te nemen foto's T te bepalen: = 225 foto's (dus 9 seconden film)
(die 225 is gekozen om het rekenwerk in dit voorbeeld wat eenvoudiger te maken, je computer kan elk aantal foto's aan)

Het gedeelte van de constante snelheid is nu dus 650 - 100 - 150 = 400 mm lang.
Noem de snelheid daarover v_max.
De gemiddelde snelheid gedurende acceleratie en deceleratie is dan v_max / 2.
Snelheid v kan je uitdrukken in (verplaatsing y) per (foto x), als je op elke geheeltallige waarde van x een foto maakt.

Het totaal aantal foto's wordt daarmee:



En dit levert:



Als we kiezen voor N_foto's = 225, dan is v_max = 900 / 225 = 4 [mm/foto]

Merk op:
- de gemiddelde snelheid over acceleratie is dus 2 mm/foto, dat levert 50 foto's over de eerste 100 mm
- dan 400 mm met constante snelheid v_max, dat levert 400 / 4 = 100 foto's
- tenslotte deceleratie: v gemiddeld = 2 mm/foto, dus 75 foto's over de laatste 150 mm

De plaatsen y(f) van je foto's haal je uit de bewegingsformules.

Voorbeeld: tijdens acceleratie geldt:
v(f) = a * f + v(0)
met onze waarden:
v(50) = a * 50 + 0
ofwel
4 = a * 50
dus
a = 0.08

Voor de eerste 50 foto's krijgen we zo:

y(f) = (1/2) * a * f^2 = 0.04 * f^2

Na positie y=0 wordt de eerste foto gemaakt op afstand: y(1) = 0.04
vervolgens de tweede op y(2) = 0.16
dan y(3) = 0.36
etc.
tot aan f(50) = 100 mm

Soortgelijk voor de andere onderdelen van je traject.

[fredvr]

Ben nog wat aan het stoeien geweest met parabolen etc maar dat gaat hem allemaal niet worden.
Dit ziet er echter top uit en lijkt het gewenste resultaat te geven.

Ga ik mee aan de slag!

[fredvr]

De 1e resultaten zien er meer dan bemoedigend uit en gaan exact de kant op die ik nastreef!! Heb eea even in een klein programma gezet met de waarden uit het voorbeeld en daarvan de output mbv excel in een grafiekje gezet.


Ik heb op het laatste deel van het traject heb domweg de methode van de acceleratie overgenomen maar dan heb ik daar uiteraard geen deceleratie... Dat zal ik nog op eoa manier moeten om toveren zodat de curve daar dalend wordt ipv stijgend.

[fredvr]

Ik ben een blij mens en heb nu precies waar ik naar op zoek was.
Hier was ik zelf niet uit gekomen. Muchas Gracias!!!

Deze curves geven het resultaat weer uit het programmatje icm de parameters uit het voorbeeld en nog eentje waar ik er wat mee gevarieerd heb.
Voor de praktische uitwerking blijven de uiteindelijke berekeningen redelijk simpel en zonder zware floating point toestanden, zodat de omvang van de functies en de belasting van de processor ook reuze meevallen. Daar was ik eerst wat bang voor.

Ziet er m.i. perfect uit.

[arie]

Mooi!
Opmerking (wellicht ten overvloede):
Om de belasting van de processor laag te houden kan je y(f) recursief bepalen,
dus vanuit y(f-1) en v(f-1).
Dan heb je in de acceleratie- en deceleratie-fase slechts 2 optellingen nodig:
- verhoog v met een constante a,
- verhoog y met v,
en in de fase met constante snelheid maar 1:
- verhoog y met v.

Je code zal er dan zoiets gaan uitzien (met de waarden die ik hierboven gebruikt heb):

Code: Selecteer alles

[1] acceleratie:
f = 0, a = 0.08, v = -a/2, y = 0
zolang f < 50:
    f = f + 1
    v = v + a
    y = y + v
    output(y)

[2] constante snelheid:
f = 0, v = 4, y = 100
zolang f < 100:
    f = f + 1
    y = y + v
    output(y)

[3] deceleratie:
f = 0, a = -4/75, v = 4.0 - a/2, y = 500
zolang f < 75:
    f = f + 1
    v = v + a
    y = y + v
    output(y)

PS: Je initialiseert v met een extra term -a/2 omdat je je y berekent met de gemiddelde snelheid tussen f-1 en f, en niet met de eindsnelheid van het laatst afgelegde trajectdeel.

[fredvr]

Helaas ligt dat in mijn geval hier wat lastiger.

Het gaat om een steppermotor dus moet steeds de positie vertalen naar een verschuiving tov de huidige positie. Hierbij moet ik weer rekening houden dat ik alleen maar hele stappen kan uitvoeren en niet met decimalen kan werken. Afronden kan niet want dan verlies ik decimalen of krijg er over het hele traject posities bij waarmee ik op het eind van het traject mogelijk niet goed uitkom.
Wat ik dus doe is in een apart veld de decimalen optellen. Zodra deze >1 is dan tel ik het aantal integers op bij de verschuiving en verminder ik daarmee 'het decimalen veldje' dat daardoor weer <1 wordt, etc, etc. Zo gooi ik geen posities weg.
bv newpos= 23,456567 (berekent dus ahv die formules)
betekent 23 steps uitvoeren en die 0,456567 bewaren en optellen bij de vorige decimalen.

dist is het aantal steps waarmee de stappenmoter de camera veroplaatst.

Code: Selecteer alles

         interval= newpos- lastPos;
	stepDist= (unsigned int) interval;  // verlies decimalen weg
	fraction+= (interval - stepDist);   // tel decimalen op bij 
	stepDist+= (unsigned int) fraction; // add fraction int value 
	fraction-= (unsigned int) fraction; // keep fraction content < 1.0		
	lastpos= newpos; 

hiermee kan ik in het begin van de acceleratie krijgen die er ongeveer uitziet als:
0 0 0 1 0 0 1 0 1 1 0 1 2 1 1 2 1 2 2 etc, etc Als curve ziet die er heel mooi vloeiend uit.

Het stukje code ziet er ongeveer zo uit op dit moment

Code: Selecteer alles

cMove is de gemm afstand voor de constante verplaatsing
uRampFactor is a voor de acceleratie
GetStepDist(pos) berekent dus de feitelijke verplaatsing voor het betreffende frame en maakt gebruik van het stukje code hierboven
dPos is de positie aan het begin van de deceleratie. Die gebruik ik omdat de deceleratie in feite de omgekeerde acceleratie is. Het is gewoon het staartstukje dat ik bij dPos optel.

if ( movingFrameCnt <= uFrames ) {
   pos= 0.5 * uRampFactor * movingFrameCnt * movingFrameCnt;
   dist= GetStepDist( pos );
   }
else if ( movingFrameCnt < dStartFrame ) {
  pos+= cMove; 
  dist= GetStepDist( pos );
}	
else if ( movingFrameCnt < nofMovingFrames ) {
  if ( movingFrameCnt == dStartFrame ) {
     dPos= pos;
     dRampCnt= dFrames- 1;
  }
  pos= ( -0.5 * dRampFactor * dRampCnt * dRampCnt);			
  dist= GetStepDist( dPos+ dRampSteps+ pos );
}
								    
movingFrameCnt++; 

De timelapse kan beginnen en eindigen zonder verplaatsing en pas na een bepaalde tijd ingezet worden.
Bij iedere verplaatsing stuur ik ook de fotocamera aan worden allerlei andere zaken afgehandeld. Ik doe dit allemaal in een slave processor en wordt er tussendoor ook met de masterprocessor gecommuniceerd en allerlei andere zaken afgehandeld.
Eea heb ik in een vaste programmastructuur opgenomen en wordt er continue 1 grote loop doorlopen. Ik kijk dan of de camera verplaatst moet worden en als dat zinnig is voor een bepaald framenr bereken ik die dan voor dat specifieke frame.

Naast timelapse is er ook nog andere functionaliteit die in principe op eenzelfde manier wordt afgehandeld. Het zo efficiënt mogelijk in een recursieve loop alle posities berekenen ligt hier dus niet zo voor de hand.
Wellicht kan het beter maar dit is de weg die ik op dit moment al een tijdje ben ben ingeslagen.
Wel erg bedankt voor het meedenken want jouw opmerking is natuurlijk heel zinvol.