Ein Herzliches Hallo in die Mikrocontroller.net Gemeinde! == DANKSAGUNG @Mikrocontroller.net == Vorweg nochmal ein großes Danke für alle die mir und meinen Schulkameraden vor einigen Jahren geholfen haben. Damals hatten wir ein Mikrocontroller-Projekt welches mit eurer Unterstützung mehr als geklückt ist so das wir zum Ende mit einer 1 rausgehen konnten. Es handelte sich damals um einen Roboterbau und war Teil einer Schulausbildung :) THX nochmal! Leider ist mir weder der Benutzername noch E-Mail bekannt - Musste mich daher neu registrieren :( Nach all den Jahren habe mir ein neues Projekt zum Ziel gesetzt, allerdings diesmal rein privat. Es handelt sich um folgendes: - Erfassung der menschlichen Gelenke über 3-Achsen-Gyroskop, 3-Achsen-Beschleunigungssensor und 3-Achsen-Magnetsensor (Motion capture) - Signalleitungen zu allen Gelenksensoren und dessen anschließende Weitergabe an eine Haupteinheit im Rücken-Bereich - Die Haupteinheit soll die gemessenen Bewegungen über WLAN weitergeben. - Der PC soll dann die gesammelten Daten in QT aufbereitet zur Verfügung stellen. Im groben soll es damit möglich sein jede Bewegung des Menschen digital abbilden zu können so das diese in virtuelle Umgebungen eingebunden werden können. Damals hatte ich mit einem Atmega644P gearbeitet und erst wenig mit der Mikrocontroller-Thematik zu tun gehabt. Ich selbst kann kein abgeschlossenes Studium im Bereich der Eletrotechnik vorweisen weil ich mich schlichtweg für den Weg der Informatik entschieden habe. Alles von Widerstand über LED bis zum Microcontroller habe ich mir daher in meiner Freizeit (in Kombination mit einigen Fehlschlägen ;) ) selbst erarbeitet. Für meine Projekt-Planung stehe ich nun vor folgenden Fragen und bin mir sicher das Ihr mir weiterhelfen könnt. A: >> Welche(n) Microcontroller würdet Ihr mir empfehlen? Die aktuelle Position würde ich gerne bereits bei den Gelenken berechnen lassen um den "Traffic" auf den Signalleitungen klein halten zu können. Mit meinem damaligen 8-Bit Atmega @20Mhz werde ich wohl kaum mit weit kommen. Für Testzwecke wäre eine Bauweise fürs Lochraster sicher nicht verkehrt. Die Adapter für LQFP etc. kosten mir zu viel Geld. IO-Pins werden eher weniger gebraucht. Würde mir ja gerne einen 32-Bit zu legen aber ich sehe da den Wald vor lauter Bäumen nicht mehr. Cortex-AM-"XYZ", ARM7 ? - Ich weiß es nicht. B: >> Welche Möglichkeit hätte man für das Weitergeben der Daten an die Haupteinheit? Ich weiß nicht welche BUS-Systeme es gibt welche es ermöglichen würden mehrere Slaves anzuschließen und zugleich auch dafür geeignet wären schnell die Daten über längere Kabel >zeitnah< weiterzugeben. Die Daten sollen sich ja schließlich im Millisekunden-Bereich am Rechner ankommen. C: >> Daten von der Haupteinheit zum PC? Womit am schnellsten? Die schnellste Übertragung wäre über ein Kabel - Entfällt aber aufgrund der Beweglichkeit der Person. Würde ein xBee überhaupt für mehrere Messungen in der Sekunde zuverlässig übertragen können? (Natürlich auch hier wieder Millisekunden) Auf Kameras möchte ich bei diesem Projekt bewusst verzichten weil diese schlichtweg nicht bezahlbar sind sobald es in den professionellen Bereich geht. Darüber hinaus benötigt die optische Erkennung immer Bezugspunkte am Körper eines Menschen. Falls dennoch derartige Vorschläge kommen sollten: Wirklich lieb gemeint von euch, aber leider keine Option für mein späteres Vorhaben. Es passt leider nicht, alleine schon aufgrund der Beweglichkeit welche vorrausgesetzt wird. Ich freue mich über jede Hilfe! :)
Hallo 1.) Hast du schon eruiert wie viele Daten du pro Sekunde an deinem PC brauchst ? Also du hast pro Gelenk 6 Messwerte. Angenommen die haben 16 Bit Auflösung bei einer Updatezeit von 50ms. 6 x 16Bit x 50 mal pro sekunde -> 4.800 Bit/s pro Sensor Also kannst fast alles nehmen als Bus die einzige Frage ist die Verdrahtung! Du kannst jetzt zB 4 I2C Busse nehmen. Was auch vielleicht ginge wäre ein Schieberegister auf UART Basis. Also jeder Sensor hat 2 UARTs. Die Sensoren werden nacheinander geschaltet und die Daten werden durch den µC durchgeschleift. Als Master auf dem Rücken kannst ja einfach sowas wie ein Raspery Pi nehmen. Wennst lieber was Bluetooth sein soll es gibt von Nordic Semiconductor SOCs mit Cortex M3 + Bluetooth Smart (1 Mbit -> praktisch weniger möglich). Also Controller kannst fast alles verwenden weil du eh nur Datenschaufeln tust. Angelo M. schrieb: > Auf Kameras möchte ich bei diesem Projekt bewusst verzichten weil diese > schlichtweg nicht bezahlbar sind sobald es in den > professionellen Bereich geht. Darüber hinaus benötigt die optische > Erkennung immer Bezugspunkte am Körper eines Menschen. Naja Kinect oder Xtion ist in meinen Augen bezahlbar als Technik. Aber warum einfach wenns auch komplex geht ^^
Hey patsch007, danke für deinen Beitrag! patsch007 schrieb: > 1.) Hast du schon eruiert wie viele Daten du pro Sekunde an deinem PC > brauchst ? > > Also du hast pro Gelenk 6 Messwerte. Angenommen die haben 16 Bit > Auflösung bei einer Updatezeit von 50ms. > > 6 x 16Bit x 50 mal pro sekunde -> 4.800 Bit/s pro Sensor Ausgerechnet hatte ich es noch nicht aber aber das liegt einfach daran weil ich noch nicht so recht weiß wieviele Bits pro Gelenk wirklich anfallen werden. Es ist ja das verschiedene Algorithmen pro Gelenk greifen werden um die aktuelle Position bestimmen zu können und da weiß ich nicht ob es wirklich sinnvoll ist unnötige "Rohdaten" an die Haupteinheit zu schicken. Ausgerechnet werden müssten diese so oder so, das ist klar. Die Sensor-Informationen könnten direkt am Gelenk berechnet werden. Dass hätte (das glaube ich zumindest) den Vorteil das man das System um beliebige Sensoren erweitern könnte ohne das die Haupteinheit mehr Rechenoperationen ausführen muss. Das ganze wäre modular erweiterbar. Lediglich der Traffic von der Haupteinheit zum PC würde natürlich mit zusätzlichen Sensoren zunehmen. patsch007 schrieb: > Also kannst fast alles nehmen als Bus die einzige Frage ist die > Verdrahtung! > Du kannst jetzt zB 4 I2C Busse nehmen. Was auch vielleicht ginge wäre > ein Schieberegister auf UART Basis. Also jeder Sensor hat 2 UARTs. Die > Sensoren werden nacheinander geschaltet und die Daten werden durch den > µC durchgeschleift. Das ist nämlich genau die Frage. Aufgrund der Beweglichkeit wäre es natürlich stark vom Vorteil wenn so wenig Leitungen wie möglich anfallen. Man darf nicht vergessen das jeder Gelenk-Sensor auch mit Strom versorgt werden muss ( Akkus sind Käse ;) ). Wäre natürlich klasse wenn man für das entsprechende Bus-System keine 4 Leitungen + Strom legen muss. Daher die Frage welche sich wohl am besten dafür eignen. Anforderungen sind ja zum einen denke ich auch die Kabellängen. Es gibt Bus-Systeme bei denen sind 30cm schon kritisch?! patsch007 schrieb: > Als Master auf dem Rücken kannst ja einfach sowas wie ein Raspery Pi > nehmen. Die Idee ist gut, hatte ich gar nicht auf`m Schirm! Ich selbst besitze 2 Stück, diese haben ja sogar fürs erste ein LAN-Interface. Danke für den Hinweis! :) patsch007 schrieb: > Also Controller kannst fast alles verwenden weil du eh nur > Datenschaufeln tust. Bist du dir da sicher? Wenn es um die Rohdaten geht und das direkte Weiterleiten - Dann bestimmt. Ein 32-Bitter kann halt mit größeren Zahlen umgehen und brauch weniger Rechenoperationen. Dadurch performanter als ein 8-Bitter. Wobei ich etwas hier auf Mikrocontroller.net gelesen hatte das auch das nicht immer stimmt. Muss mir den Artikel wohl nochmal zu Gemüt führen. patsch007 schrieb: > Naja Kinect oder Xtion ist in meinen Augen bezahlbar als Technik. > Aber warum einfach wenns auch komplex geht ^^ Sind ansich spannende Projekte nur funktioniert es leider nicht für mein Vorhaben. Die Person befindet sich (fürs erste) in einem selbst gesteckten Bereich (Begrenzungspfähle) welcher sich über mehrere Meter erstrecken kann. So viele Kameras kann ich gar nicht aufbauen. Aber für das Herumhampeln daheim im Wohnzimmer ist sowas eine coole Sache, gar keine Frage ;)
:
Bearbeitet durch User
Angelo M. schrieb: > Man darf nicht vergessen das jeder Gelenk-Sensor auch mit Strom versorgt > werden muss ( Akkus sind Käse ;) ). Wäre natürlich klasse wenn man für > das entsprechende Bus-System keine 4 Leitungen + Strom legen muss. Daher > die Frage welche sich wohl am besten dafür eignen. Anforderungen sind ja > zum einen denke ich auch die Kabellängen. Es gibt Bus-Systeme bei denen > sind 30cm schon kritisch?! Theoretisch würde ein Kabelpaar reichen zum Übertragen von Daten (bidirektional) + Strom. Ist aber dann etwas aufwändiger von der SW und HW. Preis natürlich auch höher. Wennst PCI-Express 3.0 verwenden willst hast wohl recht mit 30cm aber bei den von dir benötigten Takten hast da kein Problem gegebenenfalls musst terminieren... Angelo M. schrieb: > Bist du dir da sicher? Wenn es um die Rohdaten geht und das direkte > Weiterleiten - Dann bestimmt. > Ein 32-Bitter kann halt mit größeren Zahlen umgehen und brauch weniger > Rechenoperationen. Dadurch performanter als ein 8-Bitter. > Wobei ich etwas hier auf Mikrocontroller.net gelesen hatte das auch das > nicht immer stimmt. Muss mir den Artikel wohl nochmal zu Gemüt führen. Ich würde mir zuerst mal überlegen welche Sensoren du verwendest und wieviele Samples von den geliefert werden sollen. Dann kannst dir überlegen was du für einen Prozessor brauchst. Musst irgendwas rechnen dann ist der ARM dein Freund sonst ATmega oder so. Bei den ARM muss man auch Vorsichtig sein wegen den Befehlssätzen (Cortex M 0, M3 und M4).
Salu Ich nehme, wenn ich frei bin und einige Sensoren vernetzen muss, gerne einen CAN-Bus. Überlege doch mal ob das für Dich eine Alternative wäre. Gruss
Ich finde den CAN-Bus für den privaten Gebrauch ein wenig schwierig, da er sich bei Problemen nicht so schön am Oszi debuggen lässt. Anders schaut es natürlich aus, wenn man ein Oszi hat, das den Bus interpretieren kann. Klar getrennte Leitungen für Clock und Daten sind einfach leichter für den Anfang. Hast du dir auch schon mal überlegt was dich deine Hardware kosten wird? Die vielen Sensoren dürften nicht gerade billig werden (vor allem die Gyros).
reflection schrieb: > Ich nehme, wenn ich frei bin und einige Sensoren vernetzen muss, gerne > einen CAN-Bus. Überlege doch mal ob das für Dich eine Alternative wäre. patsch007 schrieb: > Theoretisch würde ein Kabelpaar reichen zum Übertragen von Daten > (bidirektional) + Strom. Ist aber dann etwas aufwändiger von der SW und > HW. Preis natürlich auch höher. Brechpunkt schrieb: > Ich finde den CAN-Bus für den privaten Gebrauch ein wenig schwierig, da > er sich bei Problemen nicht so schön am Oszi debuggen lässt. Anders > schaut es natürlich aus, wenn man ein Oszi hat, das den Bus > interpretieren kann. Klar getrennte Leitungen für Clock und Daten sind > einfach leichter für den Anfang. Danke für den Vorschlag! Leider bin ich nicht im Besitz eines Oszilloskops. Wenn ich das Geld zusammen habe werde ich mir sicher mal ein gutes kaufen aber bis dahin werde ich wohl ohne auskommen müsen. Fürs erste wird es daher wohl auf 4 Leitungen hinauslaufen. Bidirektional + Strom macht die Geschichte leider nochmal `n ganzes Stück teurer. Und das wohlgemerkt für jeden Gelenksensor! Brechpunkt schrieb: > Hast du dir auch schon mal überlegt was dich deine Hardware kosten wird? > Die vielen Sensoren dürften nicht gerade billig werden (vor allem die Gyros). Ich habe mir selbst das Ziel gesteckt das ich pro Gelenksensor unter 18€ bleibe. Für den menschlichen Körper komme ich auf 12 Sensoren. Hinzu kommt dann noch das Empfängermodul (PC) und die Haupteinheit auf dem Rücken. Die Sensoren habe ich alle aus dem Ausland bestellt welche dort zu einem Bruchteil erworben werden können. Hier in DE haben die Sensoren zu viel Marge mit jedem weiteren Zwischenhändler. Dauert zwar um einiges länger bis diese da sind aber ich hab auch ehrlich gesagt nichts zu verschenken ;) Die Tage habe ich bereits einiges geschafft und bin auch an manchen Dingen gescheitert. - GESCHEITERT : Cortex M3, LQFP144 auf einer Adapter-Platine zu platzieren um mit Lochraster-Platinen arbeiten zu können. (Ganz klar gescheitert -> R.I.P. ) - ERFOLG! : Versuchsaufbau mit Atmega644P + UART-2-USB (CP2012) + Sensoren - ERFOLG! : Anwendung für MAC, Linux & Windows programmiert. Es empfängt die gesammelten Daten und gibt diese aufbereitet als TCP & UDP-Stream weiter. - INFO : Mit "Target! 3001" habe ich ein PCB entworfen. Für mich wäre (Betonung liegt auf WÄRE) es meine erste Platine welche ich vielleicht in Auftrag gegeben HÄTTE wenn es nicht so verdammt teuer wäre! SMD kann ich nicht löten, habe aber vor damit in Serie zu gehen wenn es gut läuft. Alleine für die Bestückung lag der Preis bei glaube ich 140€! Derzeit spiele ich mit dem Gedanken mir selbst eine Ätzvorrichtung zu kaufen oder zu bauen und erstmal mit DIP-Gehäuse zu arbeiten. (Bisher reichte immer Lochraster) Den Gedanken einen zügigen Mikrocontroller (Pro Gelenksensor) zu verbauen habe ich verworfen. Wie patsch007 bereits zu Beginn schon geschrieben hat werde ich versuchen die Daten schnellstmöglichst zu übertragen so das diese zunächst weitergeschliffen werden. Das senkt auch die Kosten pro Gelenksensor enorm. Der Gedanke mit dem Raspberry Pi ist ansich nicht verkehrt, zum anderen ist dort sowieso ein ARM verbaut. SPI, I²C, UART hat der Raspberry Pi onboard. Arbeitet @ 700 MHz (ARM1176JZF-S). Mal schauen wie sich der einbinden lässt.
:
Bearbeitet durch User
Angelo M. schrieb: > - GESCHEITERT : Cortex M3, LQFP144 auf einer Adapter-Platine zu > platzieren um mit Lochraster-Platinen arbeiten zu > können. > (Ganz klar gescheitert -> R.I.P. ) Für die Leute die etwas Probleme mit dem Löten haben gibts von NXP den kleinen Freunde: http://www.digikey.at/product-detail/de/LPC1114FN28%2F102,12/568-10143-5-ND/3430860 Angelo M. schrieb: > Ich habe mir selbst das Ziel gesteckt das ich pro Gelenksensor unter 18€ > bleibe. Was kosten dich die Sensoren selbst ? Ich sag mal so µC + PCB in größerer Stückzahl sind sicher um 5 € wenn sogar nicht noch weniger zu fertigen. Angelo M. schrieb: > SMD kann ich > nicht löten, habe aber vor damit in Serie zu gehen wenn > es gut läuft. Alleine für die Bestückung lag der Preis > bei glaube ich 140€! Derzeit spiele ich mit dem > Gedanken mir selbst eine Ätzvorrichtung zu kaufen oder > zu bauen und erstmal mit DIP-Gehäuse zu arbeiten. Naja ist alles eine Frage der Übung, wenn man etwas Übung hat kann man auch ohne Probleme ein TQFP144 Gehäuse löten. Aber ich würde dir SOIC usw als Gehäuse form nahelegen.
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.