Hallo an alle, seit einigen Tagen stehe ich nun schon vor einem Problem und selbst Tante Google konnte mir nicht erfolgreich helfen. Daher hoffe ich hier auf eine Antwort. Es geht um folgendes: An der Uni hat ein Team von Studenten einen kleinen Rennwagen gebaut. Diesen wollen wir nun mit einem Haufen Messtechnik ausstatten, um unseren Fahrer besser auszubilden und das Fahrwerk zu optimieren. Insegesamt wollen wir 15 Sensoren im Auto verbauen (Drehzahl, Wegmesser, Gyroskop, usw.). Welche Sensoren genau verwendet werden sollen, steht noch nicht fest, allerdings würde ich hier analoge Sensoren bevorzugen, da diese leichter und auch ohne Delay ansprechbar sein sollten. Als Herzstück der Anlage plane ich momentan einen "Arduino Mega 2560" ein, der die Messwerte auslesen und speichern soll. Jetzt kommt aber mein Problem ins Spiel. Die gemessenen Werte sollten sich natürlich alle auf den gleichen Zeitpunkt beziehen. Mit dem Arduino kann ich die analogen Pins aber alle nur nacheinander abrufen und die Werte zwischenspeichern. Alleine das Auslesen der analogen Spannungen dauert rund 100 Mikrosekunden und dann kommt noch das Speichern des Zahlenwertes in einem String dazu (Dafür habe ich leider keinen Zeitbedarf gefunden). Meine Beführchtung ist, dass eine zu große Zeitspanne zwischen dem Auslesen des ersten und des letzten analogen Wertes ensteht und diese somit nicht mehr unbedingt vergleichbar sind. Hat jemand von Euch vielleicht etwas Erfahrung damit und kann mir sagen, ob die Beführchtung gerechtfertigt ist? Oder hat jemand von Euch eine Idee, wie ich alle Werte für den gleichen Zeitpunkt bestimmen könnte? Vielen Dank für Eure Hilfe. Viele Grüße Max
Was mir einfällt: Für jeden Sensor einen µC, die auf Kommando die Analogdaten samplen und abspeichern - wie ein Latch.
MoinMoin, Vorschlag: "Schaltet" vor jeden Sensor eine kleine MCU (z.B. einen ATtiny). Der Mega2560 schickt dann nur noch einen Impuls auf eine Leitung, der in jedem "dezentralen" ATtiny einen Interrupt auslöst und die entsprechende messung vornimmt/abspeichert. Irgendwann später sammelt dann der 2560 die Messwerte von den dezentralen MCUs ein (z.B. via SPI, TWI oder UART etc.) Grüße Uwe
Ihr seid Ingeniere und keine Künstler. Warum benutzt ihr also Arduino? Max Maier schrieb: > Alleine das Auslesen der analogen Spannungen > dauert rund 100 Mikrosekunden und dann kommt noch das Speichern des > Zahlenwertes in einem String dazu (Dafür habe ich leider keinen > Zeitbedarf gefunden). Lässt vermuten, daß du keinerlei Erfahrung in µC Programmierung hast. Ihr seid ein Team von Studenten? Also holt euch jemanden ins Team, der sich mit µCs auskennt und C programmieren kann. Einen Zahlenwert speichert man nie als String, ein String wird er höchstens zur Visualisierung oder bei Übertragung zu einem anderen System. Zum rechnen bleibt der Wert was er ist, ein Integer Nemt euch einen µC der genügend IO und auch Leistung hat, es gibt soviel preiswerte am Markt, von kleinen 8 Bittern zu 16 oder 32 Bittern die dann ggf. mit einem Echtzeitbetriebssystem daherkommen. Spart nicht am falschen Ende wenn das Projekt Rennwagen länger läuft, ganz schnell kommen mehr Wünsche für die Datenerfassung/verarbeitung dazu. Ein leistungsfähiges Sytem kann in 20µS deine 16 Kanäle erfassen und wandeln (wenn davor die Hardware stimmt) dann hast du praktisch "gleichzeitige" Erfassung. Schaut mal bei MSP430 oder ARM.
Was evt. geht, allerdings aufwendiger ist, dass du bei jedem Sensor ein
ATTiny nimmst, der die Werte erst mal zwischenspeichert.
Für den Timestamp einen extra RTC der alle Tinys gleichzeitig triggert.
In der Zwischenzeit, also zwischen den Messungen, die alle gleichzeitig
laufen und auch gleich lang brauchen, kann man die daten von der kleinen
Sensoplatine mit dem Tiny in den Ardunio Mega2560 schieben, der diese
dann abspeichert oder gleich auch verarbeitet.
So hättest du die Tinyplatinen alle gleich (incl.programmierung), und
mit dem Interrupt vom RTC kannst du alle gleichzeitig antriggern wobei
dann der Ardunio auch weiß das er eine feste Pause einlegen muss, in der
die Sensoren ausgelesen werden.
RTCInterrupt --> ATTiny Messen --> Daten bereitstellen tun auslesen
| |
-> Mega256 pause --> Daten von Sensoplatin auslesen und
speichern.
Es kommt natürlich darauf an, in welchen Zeitabständen du messen
möchtest.
Ich weiß jetzt nicht im Kopf was der 2560 an Speicher mitbringt, oder ob
du noch extra Speicher brauchst.
Nach der Fahrt kann man dann die gesammelten Werte auslesen und
auswerten.
Erster Grundsatz: analoge Signale sind störempfindlicher als digitale. Also moglichst digitale Sensoren verwenden. Drehzahlen und Wegstecken/Radumdrehungen bekommt Ihr ohnehin digital als Zählimpulse, die üblichen MEMS-Accelerometer und Gyroskope sind auch digital, zB das hier: http://www.invensense.com/mems/gyro/mpu6050.html http://playground.arduino.cc/Main/MPU-6050 Wenn Ihr analoge Größen synchron messen müsst, gibt es zwei Möglichkeiten: 1. externe ADCs, die gleichzeitig getriggert werden. Beispiel: MCP3201 12 Bit ADCs http://ww1.microchip.com/downloads/en/DeviceDoc/21290F.pdf Wenn Ihr 8 Stück davon nimmt, !CS und CLK verbindet und die SOUT-Pins auf einen Port des Prozessors legt, bekommt Ihr pro Takt von jedem ADC ein Bit, und nach 14 Takten habt Ihr alle 8 ADCs synchron eingelesen und müsst nur noch Eure Bits sortieren. 2. Sample&Hold Glieder, die die Analogwerte zu einem bestimmten Zeitpunkt speichern und konstant halten, damit sie anschließend ungestört von einem langsameren ADC ausgelesen werden können Ob Ihr das braucht, hängt von den Größen ab, die Ihr messen müsst. Temperaturen ändern sich nicht so schnell, da ist das eher überflüssig. Drücke oder Wegstrecken wären eher Kandidaten für so etwas. Überlegt: 1. Wie lange dauert eine Wandlung beim verwendeten ADC? 2. Welche Genauigkeit erreicht Ihr realistisch bzw braucht Ihr? 3. Um welchen Wert kann sich die Messgröße während der Wandlung maximal ändern? 4. Ich welchem Zahlenverhältnis liegen 2. und 3.? PS: Wenn Ihr Performanceprobleme haben solltet, schaut Euch das hier an: http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,892,894&Prod=CHIPKIT-MAX32 Kostet nicht viel mehr als ein AVR Arduino, hat aber wesentlich mehr Rumms. fchk
Das ist der völlig falsche Ansatz. Zuerstmal muss geklärt werden, welche Anforderungen es an die zeitliche Korrelation der Signale gibt. "Befürchten" reicht da nicht. Welche Genauigkeit soll erreicht werden? Welche Bandbreiten haben die Messignale? Wie muss demzufolge die Abtastrate sein? Vermutlich sind die 100µS bei einem relativ trägen System wie dem Rennwagen völlig unkritisch. Dann ist es evtl auch nciht wichtig, dass alle exakt zum gleichen Zeitpunkt gesampelt werden, sondern dass man weiss wann sie gesampelt wurden. Den Rest kann man i.d.r. interpolieren. Aber auch das kann man im Vorfeld berechnen/simulieren.
Hi, erst einmal ein großes Dankeschön für Eure Hilfe. > Ihr seid Ingeniere und keine Künstler. Warum benutzt ihr also Arduino? Tja, wir sind zwar Ingenieure aber halt Maschinenbauer. Und wie heißt es so schön: "Maschinenbauer können alles, aber nichts richtig" ;) Das trifft hier leider auch zu und daher wollten wir erst einmal möglichst einfach bleiben. > Lässt vermuten, daß du keinerlei Erfahrung in µC Programmierung hast. > Ihr seid ein Team von Studenten? Also holt euch jemanden ins Team, der > sich mit µCs auskennt und C programmieren kann. Naja, vor ein paar Jahren habe ich mal ein wenig mit einem ATmega8 rumgespielt aber das ist halt schon ein wenig her. Wir hätten uns auch gerne jemanden ins Team geholt, der Erfahrung damit hat, haben aber niemanden gefunden, der das freiwillig machen will. Sollte also jemand Zeit und Interesse haben, einfach melden. ;) > Einen Zahlenwert speichert man nie als String, ein String wird er > höchstens zur Visualisierung oder bei Übertragung zu einem anderen > System. Zum rechnen bleibt der Wert was er ist, ein Integer Die Werte sollen intern ja nicht ausgewertet werden, sondern auf einer SD Karte gespeichert werden und später evtl. mal über Funk an einen PC übertragen werden. Im ersten Schritt wollen wir zuerst nur eine Übertragung an einen PC, wo dann die Auswertung und Visualisierung der Werte erfolgen soll. Die ganzen Überlegungen zu einem zentralen Mega 2560 und mehreren kleinen dezentralen Untereinheiten hatten wir auch. Stellt sich nur die Überlegung, ob das nicht ein wenig zu teuer wird. ARMdran schrieb: > Zuerstmal muss geklärt werden, welche Anforderungen es an die zeitliche > Korrelation der Signale gibt. "Befürchten" reicht da nicht. Welche > Genauigkeit soll erreicht werden? Welche Bandbreiten haben die > Messignale? Wie muss demzufolge die Abtastrate sein? Mehr als Befürchtungen können wir im Moment leider noch nicht bringen, da wir relativ neu auf dem Gebiet sind und uns komplett die Erfahrung fehlt. > Vermutlich sind die 100µS bei einem relativ trägen System wie dem > Rennwagen völlig unkritisch. Die Hoffnung hatte ich auch schon, bin mir aber wegen der fehlenden Erfahrung etwas unsicher. Es wäre ziemlich ärgerlich, wenn man ein System zusammenbaut, welches am Ende nur Schrott ausgibt. Der "chipKIT Max32" sieht eigentlich ganz interessant aus. Werde mir den mal am Wochenende in aller Ruhe anschauen.
Fangt erst mal ganz klein mit einer Baugruppe an Werte zu erfassen. Mit der Zeit wächst auch die Erkenntnis. Dann könnt Ihr die Arbeit verteilen.
Also all zu teuer wird das nicht werden. Ein attiny mit en bisschen Hünerfutter kostet nicht die Welt,
Max Maier schrieb: > dauert rund 100 Mikrosekunden Wo hast Du den Wert denn her? Beim ATmega32 bspw. braucht es max. 13 ADC Takte bei 200 kHz, entspricht somit 65 uSekunden je Kanal (Normal conversions, single ended). Siehe Datenblatt des ATmega32. (Hatte gerade kein anderes zur Verfügung) Und wenn man den zusätzlichen Code zum internen abspeichern der Wert dazu rechnet, dann ergibt sich ein Zeitaufwand von ca. 2-3 ms für alle 15 Meßstellen. Nur die ADC Zeit betrachtet. Klar der 32er hat nur 8 ADC Eingänge, ab zum hochrechnen kann man das mal so annehmen. Oder? Und das ist zu langsam? Ihr solltet diese Zeiten nicht überbewerten.
Max Maier schrieb: > ARMdran schrieb: >> Zuerstmal muss geklärt werden, welche Anforderungen es an die zeitliche >> Korrelation der Signale gibt. "Befürchten" reicht da nicht. Welche >> Genauigkeit soll erreicht werden? Welche Bandbreiten haben die >> Messignale? Wie muss demzufolge die Abtastrate sein? > > Mehr als Befürchtungen können wir im Moment leider noch nicht bringen, > da wir relativ neu auf dem Gebiet sind und uns komplett die Erfahrung > fehlt. Die meisten im Maschinenbau interessten Sachen geschehen bei Frequenzen unter 1 kHz (fürs Bauchgefühl: 1 kHz entspricht einer Drehzahl von 60 000 rpm). Für die Sensoren würde ich eher Richtung digital gehen, da diese vom Prinzip her den analogen Sensoren mit kleinem µC und ADC für jeden Sensor entspricht. Ob der Sensor schnell oder langsam reagiert liegt in erster Linie an der passenden Auswahl des Sensors, weniger an der Ausführung analog oder digital. Wenn die Messwerte zum gleichen Zeitpunkt benötigt werden, sie aber zu unterschiedlichen Aufgenommen wurden, dann hat die Mathematik so viele Möglichkeiten der Interpolation auf Lager, das sich garantiert eine brauchbare finden lässt. :-) Max Maier schrieb: > Sollte also jemand > Zeit und Interesse haben, einfach melden. Dazu müsstest du uns verraten, an welcher Uni du dich befindest. Gruß Kai
Max Maier schrieb: > Die gemessenen Werte sollten > sich natürlich alle auf den gleichen Zeitpunkt beziehen. Mit dem Arduino > kann ich die analogen Pins aber alle nur nacheinander abrufen und die > Werte zwischenspeichern. Ach... ist das selbe problem wie mit jedem Prozessor der nur 1 Kern hat. Auf einem 1 Kern Prozessor kann es keine Gleichzeitigkeit geben, niemals, auf keinem 1 Kern Prozessor der Welt. Auch kein PC-Prozessor kann das, selbst wenn da Intel, AMD oder sonstwas drauf steht. Es können maximal so viele Aufgaben gleichzeitig erledigt werden, wie Kerne bzw. Prozessoren da sind. (Grundlagen Betriebssysteme) 1x 1-Kern-Prozessor: 1 Aufgabe gleichzeitig 2x 1-Kern-Prozessor: 2 Aufgaben gleichzeitig 1x 2-Kern-Prozessor: 2 Aufgaben gleichzeitig Und selbst wenn du die Aufgabe auf mehrere Prozessoren aufteilst, werden sich die ergebnise trotzdem nicht auf den gleichen Zeitpunkt beziehen, weil die Nachricht (zum speichern der Daten) nicht zeitgleich bei allen Prozessoren ankommen wird. Gesetzt dem Fall, dass ihr diese Problem beheben könnt, dann bleiben immer noch sachen wie: Temperatureinfluss auf die quarze der mC, somit "unterschiedliche" Taktraten, Phasenverschiebung (bei einem mC liegt gerade ne steigende, bei nem anderen ne fallende Flanke an) zwischen den Taktquellen der einzelnen mC, usw. Alles was ihr machen könnt ist, den Zeitversatz zwischen den Messwerten so gering wie möglich zu halten. Grüße
Max Maier schrieb: > Die ganzen Überlegungen zu einem zentralen Mega 2560 und mehreren > kleinen dezentralen Untereinheiten hatten wir auch. Stellt sich nur die > Überlegung, ob das nicht ein wenig zu teuer wird. Ihr baut einen kómpletten Rennwagen und habt Angst, dass die Controller zu teuer sind? Ich tippe jetzt mal auf Formula Student. Also springt dafür in die Etechnikfakultät und werbt euch 2 Studenten an, die schon ein bisschen Bastelerfahrung haben. Die können euch gut beraten und euch das System mit Sicherheit auch bauen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.