Beschleunigungssensor

[oratus sum]

Tagchen,

Ich hab unten ein Bild von meinen Sensorwerten hinzugefügt. Das Obere ist dabei das Gleiche nur mit einem Tiefpassfilter.

Das ein ACC Sensor von robotikhardware.de

Was ich jetzt nicht verstehe:

Misst das Ding wirklich die BESCHLEUNIGUNG? Daher müsste ich das ganze Integrieren, damit ich auf die Geschwindigkeit komme?

Das andere ist, dass ich keinen Zusammenhand sehe. Beim Übergang von
STOP nach FWD sieht man ja nen großen Ausschlag. Bei FWD zu STOP ist es aber kaum merkbar.

Hat vllt jmd Erfahrung mit dem Sensor?

Zum Graphen:

Auf der Y Achse ist der Word Wert der X Beschleunigung des Sensors aufgetragen.

Auf der X Achse die Zeit, wobei beim unteren Graphen 250ms einer Aktion entspricht. Beim oberen entspricht eine Aktion einer Sekunde.

Bei der Aktion STOP steht der Roboter still, daher wird nur die Erdbeschleunigung gemessen.
Bei der Aktion FWD fährt der Roboter vorwärts, in X Richtung.

Der Sensor ist aber Verkehrt montiert. Daher der Pfeil bei X zeigt nach hinten.

Oder auch anders geasgt, wenn der Roboter nach vorne Fährt beschleunigt er in Richtung
-X

[Manf]

So ein Sensor sollte statische Bechleunigungswerte ausgeben können.
Diese Werte kann man über den Winkel zur Erdbeschleunigung einstellen. Für einen Test wäre das eine klare Sache.
Die 3 Bilder die Du graph nennst sind nicht beschrieben.

[rideyourstyle]

Tip: wen du gleiche Skalen für die beiden Graphen nimmst, sieht mann besser der Unterschied.
Misst der Sensor wirklich in Fahrtrichtung und die erahnbaren Ausschläge sind andere Beschleunigungen bzw Fehler in der Messung?

gruss

[goara]

also die geschwindigkeit über integratiion der beschleunigung zu messen ist zwar theoretishc möglich, praktisch wird da aber nix sinnvolles bei rauskommen, allein schon wegen drift, offsetfehler und integrationsfehler...
was willst du denn genau machen??

[oratus sum]

Die Skalen kann ich ja wohl schwer machen, wenn ein Tiefpassfilter drauf ist und ich dadurch dann weniger Werte bekomme.

Ich möchte eigentlich eine Kollisionserkennung damit realisieren.

Ich werd jetzt mal ein paar Daten aufnehmen wo ich tatsächlich Kollisionen durchführe und schauen ob ich da irgendein gemeinsamen Nenner finde.

[justin]

Warum bekommst du nur wegen nem Tiefpass weniger Werte?

[goara]

@justin, weil der Tiefpass die peaks glättet --> Spitzen fallen weg und beim Autoscale werden die Diagramme gestreckter..
Wenn keine Peaks drin sind sollte es aber nicht so viel machen ausser der Tiefpass ist zu stark.... Zum vergleichen ist manuell skalieren trotzdem besser..
OK, Kollisionen sollten schon deutlich erkennbar sein.
Wenn du das dann auch noch mit den Sollwerten Koppels, also zb das wenn der bot nicht bremst, aber trotzdem starke negative beschleunigungen auftreten sollte das Erkennbar sein..

[justin]

Aber man kann doch auch mit Tiefpass genau so viele Messungen machen, oder ist der Tiefpass in Software?

[Willa]

Ich hab da auch noch eine kleine Anmerkung...:
Ich glaube deine Abtastrate ist viel zu langsam. Wenn du den ACC an deinem Kettenfahrzeug befestigst, dauert so eine Beschleunigung bis zur Endgeschwindigkeit vielleicht 0.1 Sekunden...? Also müsstest du so ca. alle 0.01 Sekunden abtasten damit zu einigermaßen zuverlässig die Beschleunigung messen kannst...
Oder beschleunigst du ganz langsam? In diesem Fall sind die auftretenden Beschleunigungen vielleicht einfach zu gering.

[oratus sum]

@Willa

Hmm das kanns natürlich sein.

Der Algo zur Abfrage + Tiefpass:


For I = 0 To 3

ACC_x = Getadc(6)

Speed_x = Speed_x + ACC_x
Next I

Speed_x = Speed_x / 4

Aber wenn der wirklich zu langsam ist, was soll ich machen? Schmitt-trigger und interrupt?

[Willa]

Wie schnell läuft denn dein Code oben ab? D.h. wie oft pro sekunde rufst du den auf? Vielleicht überträgst du die Daten auch zu langsam in dein Plot Programm, so dass die Beschleunigung zwar erfasst wird, du aber die wichtigen Datenpunkte gar nicht überträgst...
Ohne zu wissen wie das Gesamtprogramm abläuft können wir nur raten. Beschreib das doch mal in kurzen Sätzen (das ist immer besser als einen undurchsichtigen Quellcode zu posten).

[oratus sum]

Also dieser Code ist in der Hauptschleife. Wie schnell das ganze Abläuft... hmmm

Die oberen Graphen habe ich so erstellt:

Stop:
lese ACC_X aus
sende ACC_X an UART
setze Motoren auf STOP
lese ACC_X aus
sende ACC_X an UART
warte 250ms
Das Obige 10 mal ausführen

FWD:
lese ACC_X aus
sende ACC_X an UART
setze Motoren auf VORWÄRTS
lese_ACC_X aus
sende ACC_X an UART
warte 250ms
Das Obige ab FWD 20 mal ausführen

Stop:
lese ACC_X aus
sende ACC_X an UART
setze Motoren auf STOP
lese ACC_X aus
sende ACC_X an UART
warte 250ms
Das Obige 10 mal ausführen


Die ankommenden Werte habe ich dann in Excel importiert. Den Tiefpassfilter habe ich auch in Excel dann gemacht.

Den Tiefpassfilter habe ich verwendet, weil ich sehen woltle was für Werte sich dann ergeben. Ich verwende eigentlich fas immer einen Tiefpassfilter, damit ich Messfehler "glätte"

[Willa]

warte 250ms
D.h., du bekommst maximal mit 4Hz neue Daten, wenn man mal den Tiefpass außer Acht lässt. Das kann m.M. nach nicht reichen. Ich würde an deiner Stelle mal versuchen mit 400 Hz auzulesen, das kannst du dann noch Tiefpass filtern. Aber sonst bekommst du keine vernünftigen Werte, da ein ACC auch relativ stark rauscht. Ein Tiefpass macht eigentlich auch nur Sinn wenn man schnell genug ausliest - deutlich schneller als die erwartete Messwertänderung. Am besten wäre es wohl, wenn du einen freien Timer nimmst (wenn vorhanden...) der alle 2ms den adc abfragt.