Accelerometer (Sun SPOT): Forskelle mellem versioner
David (diskussion | bidrag) (New page: Accelerometeret i de fire Sun SPOTs er smart men en smule ustabilt til tider. == Kommandoer == Lidt kode relevant for accelerometer programmering. <pre> private IAccelerometer3D acc = EDe...) |
David (diskussion | bidrag) No edit summary |
||
Linje 12: | Linje 12: | ||
</pre> | </pre> | ||
== | == Bevægelse == | ||
=== Forudsætninger === | |||
Vi vil forsøge at benytte accelerometeret til at beregne bevægelsen for en Sun SPOT. Implementeringen af dette er gået ok. Der er dog en lang række faktorer, der spiller ind: | |||
* Tyngdekraften | |||
: Desværre spiller tyngdekraften ind på målinger af accelerationen. Dette betyder, at hvis Sun SPOT'en vipper en lille smule, så giver det udslag som en acceleration. Med andre tror Sun SPOT'en, at den er i et konstant frit fald, hvis man tipper den over på siden. Det er altså en væsentlig forudsætning, at bevægelsen foretages uden nogen rotation af Sun SPOT'en. | |||
* Usikkerhed på målinger | |||
: Selv når accelerometeret ligger helt stille og er nulstillet, er der stadig små udsving i målingerne. Dette gør det også brug af tærskelværdier (thresholds) umuligt. | |||
* Umuligt at foretage konstante målinger | |||
: Der bliver af praktiske årsager (beregningskapacitet på Sun SPOT'en) nødt til at være en pause mellem hver accelerometermåling. I denne pause kan der potentielt misses nogle vigtige accelerationsmålinger som f.eks. en brat opbremsning. I praksis er dette problem dog ikke så vigtigt, da man sagtens kan foretage målinger omkring hvert 5. milisekund = 200 målinger/s. | |||
=== Beregning === | |||
Vi har benyttet en simpel beregningsalgoritme til at måle bevægelsen. Fremgangsmetoden er som følger: | |||
# Hent accelerationsdata fra alle tre dimensioner samt aflæs tidspunkt for måling. | |||
# Hvis en måling er under en vis tærskelværdi sættes den lig 0. | |||
# Da målingerne foretages i g, multipliceres med den danske tyngdeacceleraion 9.82 m/s^2 for at få accelerationen i m/s^2 | |||
# Position beregnes vha. simpel dobbelt integration. For to på hinanden følgende målinger tages gennemsnittet af deres værdier og danner basis for beregningen. Dette kan retfærdiggøres ved, at vi foretager så mange målinger per sekund, at usikkerheden formindskes og at vi i praksis heller ikke har mulighed for at måle accelerationen imellem to værdier. Nedenfor er beregningen vist i x aksens retning: | |||
<math> | |||
\begin{array}{lcl} | |||
sx_0 &=& 0 m\\ | |||
vx_0 &=& 0 \frac{m}{s}\\ | |||
ax_0 &=& 0 \frac{m}{s^2}\\ | |||
t_0 &=& 0 ms | |||
\end{array} | |||
</math> | |||
Farten:<br /> | |||
<math> | |||
vx_n = \sum_{i = 1}^n \left( \frac{ax_i + ax_{i-1}}{2} \right) \cdot \left( \frac{t_i - t_{i-1}}{1000 \frac{ms}{s}} \right) | |||
</math> | |||
Stedet:<br /> | |||
<math> | |||
vx_n = \sum_{i = 1}^n \left( \frac{vx_i + vx_{i-1}}{2} \right) \cdot \left( \frac{t_i - t_{i-1}}{1000 \frac{ms}{s}} \right) | |||
</math> | |||
Bevægelsesberegningen kan foretages to forskellige steder, og vi har identificeret nogle fordele og ulemper ved begge metoder: | |||
# På Sun SPOT'en | |||
#: Fordele: | |||
#:* Aflaster radiokommunikationen da der er behov for afsendelse af færre pakker. Der sikres dermed en mere stabil kommunikation. | |||
#:* Sun SPOT'en får en reel funktionalitet i stedet for bare at sende data. | |||
#: Ulemper: | |||
#:* Der mistes fleksibilitet til at behandle accelerationsdataene, da Sun SPOT'en ikke har hukommelse til at gemme en historik over disse men kun kan gemme sin nuværende accelerations-, hastigheds og stedvektor. | |||
# På basisstationen med data fra Sun SPOT'en. | |||
#: Fordele: | |||
#:* "Ubegrænset" hukommelses- og beregningskapacitet. | |||
#:* Mulighed for komplet historik over accelerometermålinger. | |||
#:* Hurtigere og mere overskuelig udrulning og debugging af ændringer. | |||
#:* Mulighed for at benytte forskellige beregningsmetoder for de samme accelerometerdata. | |||
#: Ulemper: | |||
#:* Tab af pakker giver store huller i dataene. | |||
Konklusionen fra disse forsøg er, at den mest effektive og stabile metode til at beregne positionen er på selve Sun SPOT'en. | |||
Ved beregning på basisstationen oplever vi massive forsendelsesproblemer, hvis der skal sikres en god mængde accelerationsdata som grundlag for beregningerne (5 milisekunders interval mellem pakkeforsendelser). Ved beregning på Sun SPOT'en kan positionen bestemmes på samme måde med 5 milisekunders intervaller, men vi nøjes med at sende en pakke med den sidst beregnede position med 100 milisekunders interval, hvilket giver meget bedre resultater, og en opdatering af positionen på 10 gange i sekundet er nok til stadig at illustrere en forholdsvis flydende bevægelse. Intervallet på 100 ms kan endda sagtens justeres, så der sendes oftere, men der opstår altså flaskehalse omkring det ønskede interval på 5 ms. | |||
== Problemer == | |||
=== Tærskelværdier === | |||
* Det ser ud til, at threshold ikke kan bestemmes 100% selv. De er nogle pre-definerede intervaller. [http://www.sunspotworld.com/docs/Purple/javadoc/ Dokumentationen] nævner intet om dette. Nogle målinger: | * Det ser ud til, at threshold ikke kan bestemmes 100% selv. De er nogle pre-definerede intervaller. [http://www.sunspotworld.com/docs/Purple/javadoc/ Dokumentationen] nævner intet om dette. Nogle målinger: | ||
** -0.01/0.01 | ** -0.01/0.01 | ||
Linje 39: | Linje 95: | ||
*** y: -0.546/0.485 | *** y: -0.546/0.485 | ||
*** z: -0.535/0.496 | *** z: -0.535/0.496 | ||
[[Category:Sun SPOT]] | |||
[[Category:Programmering (Sun SPOT)]] |
Versionen fra 9. apr. 2008, 10:38
Accelerometeret i de fire Sun SPOTs er smart men en smule ustabilt til tider.
Kommandoer
Lidt kode relevant for accelerometer programmering.
private IAccelerometer3D acc = EDemoBoard.getInstance().getAccelerometer(); ((LIS3L02AQAccelerometer) acc).setScale(LIS3L02AQAccelerometer.SCALE_6G); acc.addIAccelerometer3DThresholdListener(this); acc.setThresholds(IAccelerometer3D.ALL_AXES, lowThreshold, highThreshold, true); acc.enableThresholdEvents(IAccelerometer3D.ALL_AXES, true); // skal køres efter hver event acc.getLowThreshold(IAccelerometer3D.X_AXIS, true) // Henter nuværende lave threshold
Bevægelse
Forudsætninger
Vi vil forsøge at benytte accelerometeret til at beregne bevægelsen for en Sun SPOT. Implementeringen af dette er gået ok. Der er dog en lang række faktorer, der spiller ind:
- Tyngdekraften
- Desværre spiller tyngdekraften ind på målinger af accelerationen. Dette betyder, at hvis Sun SPOT'en vipper en lille smule, så giver det udslag som en acceleration. Med andre tror Sun SPOT'en, at den er i et konstant frit fald, hvis man tipper den over på siden. Det er altså en væsentlig forudsætning, at bevægelsen foretages uden nogen rotation af Sun SPOT'en.
- Usikkerhed på målinger
- Selv når accelerometeret ligger helt stille og er nulstillet, er der stadig små udsving i målingerne. Dette gør det også brug af tærskelværdier (thresholds) umuligt.
- Umuligt at foretage konstante målinger
- Der bliver af praktiske årsager (beregningskapacitet på Sun SPOT'en) nødt til at være en pause mellem hver accelerometermåling. I denne pause kan der potentielt misses nogle vigtige accelerationsmålinger som f.eks. en brat opbremsning. I praksis er dette problem dog ikke så vigtigt, da man sagtens kan foretage målinger omkring hvert 5. milisekund = 200 målinger/s.
Beregning
Vi har benyttet en simpel beregningsalgoritme til at måle bevægelsen. Fremgangsmetoden er som følger:
- Hent accelerationsdata fra alle tre dimensioner samt aflæs tidspunkt for måling.
- Hvis en måling er under en vis tærskelværdi sættes den lig 0.
- Da målingerne foretages i g, multipliceres med den danske tyngdeacceleraion 9.82 m/s^2 for at få accelerationen i m/s^2
- Position beregnes vha. simpel dobbelt integration. For to på hinanden følgende målinger tages gennemsnittet af deres værdier og danner basis for beregningen. Dette kan retfærdiggøres ved, at vi foretager så mange målinger per sekund, at usikkerheden formindskes og at vi i praksis heller ikke har mulighed for at måle accelerationen imellem to værdier. Nedenfor er beregningen vist i x aksens retning:
Farten:
Stedet:
Bevægelsesberegningen kan foretages to forskellige steder, og vi har identificeret nogle fordele og ulemper ved begge metoder:
- På Sun SPOT'en
- Fordele:
- Aflaster radiokommunikationen da der er behov for afsendelse af færre pakker. Der sikres dermed en mere stabil kommunikation.
- Sun SPOT'en får en reel funktionalitet i stedet for bare at sende data.
- Ulemper:
- Der mistes fleksibilitet til at behandle accelerationsdataene, da Sun SPOT'en ikke har hukommelse til at gemme en historik over disse men kun kan gemme sin nuværende accelerations-, hastigheds og stedvektor.
- Fordele:
- På basisstationen med data fra Sun SPOT'en.
- Fordele:
- "Ubegrænset" hukommelses- og beregningskapacitet.
- Mulighed for komplet historik over accelerometermålinger.
- Hurtigere og mere overskuelig udrulning og debugging af ændringer.
- Mulighed for at benytte forskellige beregningsmetoder for de samme accelerometerdata.
- Ulemper:
- Tab af pakker giver store huller i dataene.
- Fordele:
Konklusionen fra disse forsøg er, at den mest effektive og stabile metode til at beregne positionen er på selve Sun SPOT'en.
Ved beregning på basisstationen oplever vi massive forsendelsesproblemer, hvis der skal sikres en god mængde accelerationsdata som grundlag for beregningerne (5 milisekunders interval mellem pakkeforsendelser). Ved beregning på Sun SPOT'en kan positionen bestemmes på samme måde med 5 milisekunders intervaller, men vi nøjes med at sende en pakke med den sidst beregnede position med 100 milisekunders interval, hvilket giver meget bedre resultater, og en opdatering af positionen på 10 gange i sekundet er nok til stadig at illustrere en forholdsvis flydende bevægelse. Intervallet på 100 ms kan endda sagtens justeres, så der sendes oftere, men der opstår altså flaskehalse omkring det ønskede interval på 5 ms.
Problemer
Tærskelværdier
- Det ser ud til, at threshold ikke kan bestemmes 100% selv. De er nogle pre-definerede intervaller. Dokumentationen nævner intet om dette. Nogle målinger:
- -0.01/0.01
- x: -0.0632/0.00129
- y: -0.0329/-0.0329
- z: -0.0116/-0.0116
- -0.02-0.03/0.02-0.03
- z: -0.0760/-0.0116
- -0.04/0.04
- y: -0.0973/0.0316
- z: -0.0760/-0.0116
- -0.1/0.1
- x: -0.127/0.0664
- y: -0.160/0.0980
- z: -0.148/0.0451
- -0.2/0.2
- x: -0.256/0.195
- y: -0.224/0.162
- z: -0.213/0.174
- -0.3/0.3
- x: -0.320/0.260
- y: -0.353/0.291
- z: -0.342/0.238
- -0.5/0.5
- x: -0.514/0.453
- y: -0.546/0.485
- z: -0.535/0.496
- -0.01/0.01