Guten Tag Zusammen! Im Rahmen einer Technikerarbeit wollen wir eine Motorradjacke entwickeln, die bei Sturz die auftretenden Kräfte misst. Anschließend soll ein Notrufsignal agebegen werden und eine Email verschickt werden. Wir sind jetzt am überlegen welche Hardware wir dazu am besten verwenden sollen. Könnt ihr uns ein paar Tipps geben was es genau zu beachten gibt ? Funktioniert die Stromversorgung mit einer Powerbank? Empfehlt ihr ein Arduino oder ein Raspberry für unser Projekt ? Welche Shields sind empfehlenswert ? Vielen Dank im Voraus. Liebe Grüße! Yannik und Christian
Wenn ihr so fragt, dann eindeutig ein Raspberry. Für ein Notrufsignal und Email werdet ihr ein GSM Modul brauchen. Am Raspberry wird wohl auch ein einfacher günstiger Usb-Stick mit Linux Treibern genügen. Die Sensoren werden sich ähnlich einfach auslesen lassen und das Debugging wird ungleich einfacher. Klar würde man in einer realen Produktion eine besser zugeschnittene Hardware verwenden, für ein "Proof of Concept" lohnt das aber nicht.
Mein Vorschlag für euch: Integriert die Frage nach der geeigneten Hardware in eure Technikerarbeit. Aufbauend auf der Beantwortung eurer Frage überlegt ihr, welche Stromversorgung geeignet ist. Meine Empfehlung für euer Projekt lautet – zunächst den eigenen Verstand nutzen ;-)
:
Bearbeitet durch User
>Anschließend >soll ein Notrufsignal agebegen werden und eine Email > verschickt werden.Wir sind jetzt am überlegen welche > Hardware wir dazu am besten verwenden sollen. Dafür scheint mir ein Handy am besten geeignet. Und dann eine Motorad-Sturz-Ap...
chris schrieb: > Dafür scheint mir ein Handy am besten geeignet. Und dann eine > Motorad-Sturz-Ap... Sehe ich auch so. Da ist die ganze Hardware, die ihr braucht, schon drin, inkl. Akku. Die ist auch noch schön kompakt, stoß- und wasserfest verpackt. -> Die perfekte Platform für einen Proof-Of-Concept. Ein günstiges China-Handy für < 100€ ist ja völlig ausreichend Dann noch eine passende Android App mit der Sprache eurer Wahl (Kotlin, Java, C# oder JS) entwickeln und gut ists :-)
Vielen Dank für die vielen Antworten. @Joe: Was meinst du mit eigenen Verstand nutzen? In vielen Foren liest man dass das Raspberry sehr anfällig ist bei Spannungsschwankungen - vor allem wenn das Anschlusskabel zu lang ist. Wir haben es gerade getestet. Es funktioniert bis 2m. Ein Handy wäre eine Alternative, allerdings wollen wir ja selbst etwas programmieren. Also der Mikrocontroller soll die Aufgaben von einem Handy übernehmen.
Yannik N. schrieb: > In vielen Foren liest man dass das Raspberry sehr anfällig ist bei > Spannungsschwankungen - vor allem wenn das Anschlusskabel zu lang ist. > Wir haben es gerade getestet. Es funktioniert bis 2m. Deshalb solltest du auch ein Handy nehmen (neudeutsch: Smartphone). Hat den Vorteil dass dort meistens schon ein GPS drinn ist! Was nützt dir ein RPi mit Sturzerkennung und eMail wenn der Empfänger erst mal das Land nach dir absuchen muss? Geolocation hast automatisch! GGf mit Google-Account (Timeline-Funktion)
Yannik N. schrieb: > @Joe: Was meinst du mit eigenen Verstand nutzen? Nun ich nehme an, ihr meint mit der Technikerarbeit eine Abschlussarbeit an einer Technikerschule. Ist das der Fall, so wollt ihr mit dieser Arbeit eine bestimmte Qualifikation nachweisen. Ein Teil dieser Qualifikation ist die von euch genannte Projektarbeit. Sie besteht eben nicht nur aus einem Programm oder zusammengesteckter Hardware oder kopierten Lösungen, sondern aus einer didaktisch durchdachten Arbeit. An dieser Stelle darf dann zunächst der eigene Verstand ansetzen bevor Fragen nach einer Powerbank oder nach der Farbe des Gehäuses kommen.
Yannik N. schrieb: > Ein Handy wäre eine Alternative, allerdings wollen wir ja selbst etwas > programmieren. Also der Mikrocontroller soll die Aufgaben von einem > Handy übernehmen. Programmieren müsst ihr das Smartphone auch. Das tut ja nicht schon von Haus aus das was ihr wollt. Der Programmieraufwand zwischen Handy und Raspi wird vergleichbar sein, denke ich.
Ein Raspberry oder ein Handy kann man schon nehmen für eine Studie bzw. ein Funktionsmuster. Aber für ein reales Produkt würde es dann auf jeden Fall eine eigene Hardware benötigen, da man ansonsten einige Probleme nicht vernünftig lösen kann. (Stromverbrauch, Vorschriften/Zulassungen, etc.)
Felix U. schrieb: > Für ein Notrufsignal und Email werdet ihr ein GSM Modul brauchen. So etwas braucht kein USB, sondern kann auch über eine serielle Schnittstelle angesteuert werden, und damit reicht auch ein Arduino. Der verbraucht weniger Strom (was bei mobilem Einsatz nicht unwichtig ist) und muss vor allem nicht von einer empfindlichen SD-Karte gebootet werden. Beispiele für einfache GSM-Module sind SIM800L bzw. SIM900L. Da muss man zwar ein paar AT-Kommandostrings zusammenbasteln, aber das ist auch auf einem Arduino hinzubekommen.
Rufus Τ. F. schrieb: > Beispiele für einfache GSM-Module sind SIM800L bzw. SIM900L. Da muss man > zwar ein paar AT-Kommandostrings zusammenbasteln, aber das ist auch auf > einem Arduino hinzubekommen. Klar kann man. Darauf würde ich mich aber nicht festlegen wollen, wenn es nicht nötig ist. Auf einem Raspi könnte man in kürzester Zeit viele verschiedene Arten der Informationsübertragung testen. Email oder z.B. ein Service der live die Sensorwerte liefert wären jeweils wohl ein < 10 Zeilen Skript. Ich kenne die SIMnnn Module nicht aber es würde mich nicht wundern, wenn man da schon Probleme mit einem Force TLS SMTP-Server bekäme. Ich glaube einfach, dass für ein so stark vernetztes Proof of Concept Projekt ein Arduino ein unnötiger Klotz am Bein ist.
:
Bearbeitet durch User
Yannik N. schrieb: > Vielen Dank für die vielen Antworten. > @Joe: Was meinst du mit eigenen Verstand nutzen? > In vielen Foren liest man dass das Raspberry sehr anfällig ist bei > Spannungsschwankungen - vor allem wenn das Anschlusskabel zu lang ist. > Wir haben es gerade getestet. Es funktioniert bis 2m. Nö, bis 1000m. Wenn man 100mm² verwendet. Nö, nur 0,2m. Wenn man 0,001mm² verwendet. Du siehtst, wie unsinnig und wenig aussagekräftig euer Test war? @Topic Die viel interessantere Frage als die Hardware ist, wie ihr euer Problem lösen wollt. Hardwarenahe? Dann wohl Arduino oder ein anderes Controllerboard. Ein GSM-Shield, und ls gehts. Machbar ist es. In Software mit Linux? Dann wohl RaspberryPI oder ein ähnliches Linux-Board. Als Android-App? Dann mmit einem Handy. Dann könnt ihr euch sämtliche Beschäftigung mit der Hardware sparen. Drei grundverschiedene Herangehensweisen, und das hängt auch davon ab, wie ein Sturz erkannt werden soll. So wird man sich bei einem Handy schwehr tun, viele Sensoren anzuschließen. Der Raspberry PI wird mit Analogen Sensoren so seine Probleme haben. Der Ardunio dagegen wieder mit einer komplexen Rechnerei mit den Daten. Und so weiter. Da gehören erst mal die Randbedingungen definiert. Ihr macht eure ersten Schritte bei der Realisierung, habt aber noch nicht einmal das Ziel definiert. Wer so anfängt, ist bereits gescheitert.
Danke für die Antworten. @Hmm warum glaubst du schreiben wir in einem Forum einen Thread und fragen um Hilfe? Damit Leute wie du und Joe dumme Kommentare loswerden können. Ich dachte eigentlich ein Forum ist dafür da, um Hilfe zu bekommen.. Da wir noch dabei sind uns über alle Möglichkeiten zu informieren, wissen wir die sogenannten "Randbedingungen" leider noch nicht ! Davor haben wir uns entschlossen in Foren wie diesem hier mal nachzufragen. Leider sind Foren wohl mehr und mehr dafür da um rumzustänkern. Unsere Idee war es, bei Sturz auf einen Sensor (Force-Sensitive-Resistor oder Drucksensor Kraftsensor Dehnungsmesstreifen, etc.), über einen Mikrocontroller einen Alarm per SMS / Email abzusenden. Da es problematisch ist den Motorradfahrer über das Bordnetz des Motorrads zu verbinden (Leitung reißt bei Sturz -) Verbindung zum Mikrocontroller ist unterbrochen) wollten wir eine mobile Stromversorgung wie ein Akkupack verwenden. -) und nein wir wollen kein Handy als Sensor benutzen und nach Möglichkeit auch kein Handy zum versenden von Daten benutzen. Gruß
Das beschriebene Prokejekt klingt tatsächlich so, als das es am besten mit dem AHndy gelöst wird. Nun will man als Techniker gerne etwas mit Technik sehen und nicht "nur" Software. Ich würde hier wohl einen Kompromiss eingehen und das Projekt aufteilen. Die Sensoren werden durch einen Mikrocontroller (z.B. Arduino) ausgelesen und dieser sendet wie Werte via Bluetooth an das Handy. Das Smartphone wertet die Daten aus und versendet ggf. die Warnmeldung/E-mail/SMS. Da würde ich wahrscheinlich aber die Hardware in das Motorrad einbauen wollen, dort ist es vergleichsweise leicht witterungsgeschützt einzubauen, eine Stromversorgung ist möglich und die physikalischen Dimensionen (Baugröße) spielt keine so große Rolle. Zusätzlich könnte so leicht eine Erweiterung stattfinden (als Fazit/Verbesserungspotential). Z.B. könnte eine Dibstahlsicherung, GPS-Ortung, oder auch Keyless-go implementiert werden. Als Projektausblick für die Bewertung ganz nett. So hättet ihr zum einen eine Möglichkeit die Aufgabe sinnvoll aufzuteilen, zum anderen eine Schnittstelle und ein "plattformübergreifendes System mit mehreren Disziplinen". Das kommt in der Bewertung auch immer ganz gut. Statt fertiger (Sensore-)Shields ätzt euch besser selbst kleine Platinchen oder baut die Shields auf Lochrasterplatinen nach. Diese Shields habe keinen Vorteil aus sicht etwaiger Zertifizierung, vermitteln dafür allerdings den Eindruck ihr hättet es euch mit der Hardware ziemlich leicht gemacht. Im Selbstbau zeigt ihr mehr Engagement -> Bewertungsrelevant Abgesehen davon ist auf den Shields sowieso nur selten viel drauf, das bisschen Hühnerfutter bekommt man von Hand gelötet auch noch gut nachgebildet und auf kleinem Platz unter.
Yannik N. schrieb: > Leider sind Foren wohl mehr und mehr dafür da um rumzustänkern. Ich sehe das nicht als stänkern. Gut, nett formuliert war es nicht, aber es war durchaus als Hilfe gedacht! Formulieren wir das doch mal neutraler: 1. Welche Hardwareplattform man wählt, hängt davon ab welches Problem man lösen muss. Jede hat konkret vor und Nachteile. Der Arduino tut sich leicht, analoge Sensoren in Echtzeit auszuwerten. Er ist aber schwieriger zu programmieren (was komplexere Datenverabeitung angeht). Der Raspberry hat mehr Rechenkapazität, kann auch noch z.B. I2C Sensoren auswerten, hat seine Probleme aber bei der Echtzeit und analogen Sensoren. An das Handy etwas anschließen, wird schwierig, dafür ist die Hardware schon fertig. 2. Bevor man sich aber Fragen um die Plattform stellt, muss man das Ziel erst einmal kennen. Man kann nicht eine Plattform nach nicht existenten Kriterien aussuchen. Keine der genannten ist per se besser oder schlechter. Warum die "böse" Formulierung? Ich bin seit >10 Jahren Entwickler, und bei vielen solchen "Startup-Style" Projekten dabeigewesen. Ich weiß wie das läuft, und ich weiß wie es endet. Umso schludriger das Projekt beim Start, umso tiefer gehts in den Wald. Es ist keine sinnvolle Art ein Projekt derartig anzugehen. Um Strukturierte Arbeitsweise wird kein Weg herum führen. Und das ist zunächst einmal GENAU zu formulieren, was herauskommen soll. Dann kann man sich überlegen, mit welchen Sensoren das denn am günstigsten umzusetzen ist. Erst dann kann man sich überlegen, wie man das denn auswerten muss. DANN kommt die Frage nach der Plattform. Nicht früher.
>Unsere Idee war es, bei Sturz auf einen Sensor (Force-Sensitive-Resistor >oder Drucksensor Kraftsensor Dehnungsmesstreifen, etc.) Mit an Sicherheit grenzender Warscheinlichkeit sollte man einen 3D Beschleunigungssensor nehmen. Der Springende Punkt wird dann sein, Charactersitika fest zu legen, wann in den Messwerten ein Sturz erkannt wird. Das wird nicht ganz trivial sein, da es nicht reichen wird, diskrete Zeitpunkte zu betrachten. Ein Sturz wird sinngemäß eine Abfolge von Messwerten sein, die einen "Moment" lang nahe an der Schwerelosigkeit liegen (während des Fallens) und dann von einem abrupten Messwertewechsel (Aufprall) gefolgt werden. z.B. Sollte "flottes" beschleunigen und starkes bremesen natürlich nicht zu einem Auslösen eines Notrufes führen. Das zu klassifizieren, dürfte das aufwendigste sein. Warscheinlich würde es im Rahmen einer Abschlussarbeit auch reichen, das Problem auf eine Dimension zu reduzieren mit zugehöriger schriftlicher Diskussion, warum das für ein Proof-Of-Concept in Ordnung ist.
>Das zu klassifizieren, dürfte das aufwendigste sein.
Genauso ist es. Die Filter für eine zuverlässige Signaldetektion sind
der größte "Forschungsaufwand" ( immer unter der Voraussetzung, dass man
es richtig machen will).
Deshalb würde ich den "agilen" Ansatz fahren:
1. Grundlegende Ziele festlegen
2. Benchmarking ( Produkte der Konkurrenz ananlysieren, also Stärke und
Schwächen der Smartphone App )
3. Funktionsmuster schnell in Rapid Prototyping erstellen für
Realitäts-Check
4. Erreichbarkeit der Ziele anhand der bisherigen Erkenntnisse
korrigieren
5. Nochmal mit dem Produktmanagment reden und dann in die
Produktentwicklungsphase gehen
Yannik N. schrieb: > Ein Handy wäre eine Alternative, allerdings wollen wir ja selbst etwas > programmieren. Das Handy macht nichts von allein. Aber da sind alle Sensoren drin die man braucht. Im Programm die Beschleunigungen messen und bei Überschreiten von Grenzwerten der g-Kräfte ist grad ein Unfall im Gange. Dann GPS ermitteln, Position wegfunken und so weiter.
+ 1 fürs Smartphone. Da ist die Hardware schon komplett und der interkulturelle Aufwand ist derselbe.
Ich sage voraus dass sogar die Programmierung ein Android App unsere beiden Genies überfordern wird. Allerdings stelle ich auch die Frage ob die Sensoren in einem Smartphone für so was geeignet sind. Lassen sich damit auch recht hohe G-Werte messen? Grundsätzlich wäre die Aufgabe mit einem klassischen Controller (AVR, STM32), einem SIM Modul, GPS Modul und G-Sensor zu bewältigen. Diese Umsetzung ist deutlich komplexer aber im Bezug auf Größe und Stromverbrauch zu bevorzugen.
Ich würde das Ganze in Folgendem Licht sehen: Da vom TE Begriffe wie Dehnungsmesstreifen gefallen sind, nehme ich an, sind es Techniker im Elektrotechnischen- oder Mechatronischen Sinne. Da würde es an der Ausbildung deutlich vorbeigehen ein System auf Basis eines Applikationsprozessors wie RasPi oder Smartphone zu nehmen. Dann geht es außer der Messwertqualifikation nur noch um API´s und SDK´s. Das wird nicht Inhalt ihrer Ausbildung gewesen sein. Von dem Punkt her würde ich sagen: Was µController basiertes was echtzeitfähig ist (sonst klappt keine Messwertqualifikation über die Zeit), das Problem argumentativ auf eine Dimension beschränken (G-Sensor mit nur einer Messrichtung oder eben von einem mehrdimensionalem nur eine dimension nehmen) Benötigte Kommunikation (SMS etc) über Zusatzmodule z.B. über UART anbinden. Was die Position angeht vielleicht erstmal einfach Fakeposition übermitteln und wenn dann noch Zeit ist sich an einer GPS Antenne versuchen (NMEA Protokoll). Das Ganze wird selbstredend kein fertiges Produkt, aber das wird wohl auch kaum die Erwartung sein.
Mir scheint, dass auch Du die Signalverabeitung unterschätzt. Man muss sich nämlich erst mal überlegen, wie man die Auswertung verifizieren will und wo man die Meßdaten dazu her bekommt. z.B. 100 Dummies in unterschiedlichsten Szenarien gegen Hindernisse fahren lassen, mit Dattenloggern die Meßdaten aufzeichen, mit Matlab die Meßdaten auswerten und die Algorithmik entwickeln.
ChefKoch schrieb: > Ich würde das Ganze in Folgendem Licht sehen: > > Da vom TE Begriffe wie Dehnungsmesstreifen gefallen sind, nehme ich an, > sind es Techniker im Elektrotechnischen- oder Mechatronischen Sinne. Da > würde es an der Ausbildung deutlich vorbeigehen ein System auf Basis > eines Applikationsprozessors wie RasPi oder Smartphone zu nehmen. Dann > geht es außer der Messwertqualifikation nur noch um API´s und SDK´s. Das > wird nicht Inhalt ihrer Ausbildung gewesen sein. > > Von dem Punkt her würde ich sagen: > > Was µController basiertes was echtzeitfähig ist (sonst klappt keine > Messwertqualifikation über die Zeit), Genau mit der Maßgaben würde ich den Controller nicht nehmen! Wer noch nie einen µController programmiert hat, hat da hart zu beißen. Ich persönlich habe Monate gebraucht, bis mir die Controllerspielerei flüssig von der Hand ging (also von 0,0 auf passabel). Das wird sich zeitlich nur dann ausgehen, wenn da schon ein halbwegs erfahrener µControllerprogrammierer dabei ist. Was in die Planung mit einbezogen werden muss, wie auch in die Plattformauswahl logischerweise...
Nur mal so als Gedanke/Anregung: Statt die Technik in die Motorradjacke einzubauen würde ich sie evtl. eher am Motorrad selbst befestigen. Ob eine Art Unfall passiert ist, kann man dann vermutlich schon daran erkennen, dass die Maschine minutenlang unbewegt auf der Seite liegt - so etwas dürfte im Normalfall ja eigentlich nicht vorkommen. Ausserdem könnte man die Schaltung dann evtl. direkt aus der Batterie/Stromversorgung des Motorrads speisen, statt ständig irgendeinen Akku/eine Powerbank aufladen zu müssen - was man vermutlich vergisst, und einen vermutlich ausgerechnet im Notfall im Stich lässt. Und durch das integrierte GPS und GSM könnte das Ganze gleichzeitig auch noch als Diebstahlschutz etc. fungieren.
Im Grunde ein übersichtliches Projekt. Ich schreib mal die Materialliste auf. - Arduino - GPS Modul - GSM Modul+SIM-Karte - Batterie - Gehäuse + Motorad-hat-einen-Unfall Sensor Dann: Alles zusammenbauen, in sendSMS.ino die Telefonnummer für den Notarzt und den Text eingeben, fertig ;-) Kleine Rätselfrage: Was in der Liste kann man nicht kaufen?
Mal schauen, was es wirklich gibt: >- GPS Modul https://playground.arduino.cc/Tutorials/GPS >- GSM Modul+SIM-Karte+sendSMS.ino https://www.arduino.cc/en/Tutorial/GSMExamplesSendSMS
Yannik N. schrieb: > Welche Shields sind empfehlenswert ? Will man reale Aufgaben lösen, lassen die sich in der Regel nicht einfach mal eben aus ein paar Shields zusammen klicken. Reale Aufgaben benötigen Gehirnschmalz und vor allem Planung. Erstmal muß man sich ein Konzept machen, welche Sensoren sind nötig, wie montiere ich die, welche Signale liefern die, wie werte ich die richtig aus, wie prüfe ich sie auf Fehler und Sinnhaftigkeit, welche Störungen können die Messungen beeinflussen, wie erkenne ich überhaupt einen Sturz usw. usw. Die Frage nach einer konkreten CPU stellt sich erst viel später. In der Regel wird man erstmal ein DSO und einen PC nehmen, um die Signale zu erfassen und Auswerteprogramme zu erstellen. Die Aufgabe klingt allerdings nicht sonderlich anfängertauglich, will man sie auch ernst nehmen. Mehr als ein Druckknopf, der per Handy die Email verschickt, wird dabei wohl nicht herauskommen.
Wie's der Zufall so will, gestern passendes in der Wirseler Abendpost: " Familiendrama durch Übersetzungsfehler Zum Abschluss seiner Technikerarbeit hat sich Herr Y. aus N. zusammen mit seinen Kollegen nach einer Motorradfahrt zu einem kleine Umdrunk im Gasthaus "Bikers in" getroffen. Er stellte das Motorrad vor dem Gasthaus auf einer noch feuchten Wiese ab. Nach etwa einer halben Stunde fiel das Motorrad um, da der Ständer in den feuchten Boden sank. Durch das Umfallen wurde umgehen der Notarzt und die Lebensgefährtin Frau S. aus N. über eine GSM Verbindung durch die von den Technikern neu entwickelte und prämierte Elektronik zur Unfallmeldung alarmiert. Die Lebensgefährtin fuhr auf Grund der Aufregung zu schnell und wurde aus einer Kurve getragen. Herr Y. wird jetzt vom MC-Krisenpräventionsteam seelsorgerisch betreut. Eine genauere Nachforschung der Unfallursache ergab, dass der chinesische Fachhändler einen "Umfallsensor" statt eines "Unfallsensors" geliefert hatte. Dieser weist jedoch jegliche Schuld von sich und gibt der Übersetzung durch den Google-Translator die Schuld. Die europaische Union überlegt jetzt einen Einfuhrstopp für chinesische Elektronikprodukte zu verhängen. Die chinesische Regierung reagierte umgehend und warnte vor einem Einfuhrstop europäscher Motorräder mit Verbrennungsmotor. " ;-)
Mich wundert das so viele dafür sind ein Smartphone als Sensor zu verwenden. Erfahrungsgemäss sind die Sensoren von Anrdoid verpackt und gefiltert, ich bezweifle dass sich damit einen saubere Sturzerkennung realisieren lässt. @Yannik: ihr wollt wirklich eine Arbeit schreiben über Sachen von denen ihr nicht mal den Ansatz einer Ahnung habt? Ich will ja auch nicht meckern aber mir erscheint das "mutig". Aber zur Frage: Ich möchte kein Notfallgerät dass erstmal ein komplettes Linux bootet. Auch für Arduino gibt es potente HW. (viele Quadkopter fliegen mit einem Sketch auf einem STM32)
Noch mal vielen Dank an Alle. Und sorry Hmm falls das vorhin zu forsch war ;) Aber ich frage mich manchmal für was Foren da sind wenn man teils Antworten bekommen die man etwas "netter" formulieren könnte. Nun noch mal zu dem Projekt. Vielleicht sollten wir erstmal sagen was für eine Art Technikerarbeit wir schreiben / bauen müssen. Wir sind angehende Medizintechniker (staatlich geprüfter Techniker / Fachrichtung Medizintechnik) und wir müssen in einem Schuljahr ein Projekt auf die Beine stellen, das der Medizin dient, Hardware verbaut ist (wie ein Mikrocontroller) und aber auch Software genutzt wird (Datenbanken oder Programmierung, etc.) Wir sind relativ ungebunden was wir exakt machen sollen, aber es sollte von allem was dabei sein. Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und Programmierung angeht. Deshalb die Frage / Thread in diesem Forum. Unsere Idee war es über einen Sensor den Sturz zu registrieren - und je nachdem wie stark der Aufprall ist eine Art Verletzungsprognose an den Arzt weiterzuleiten. (medizinischer Teil) Als Beispiel: Der Motorradfahrer hat einen Frontalzusammenstoß mit einem Auto. Der Sensor der im Brustbereich angebracht ist registriert den Aufprall, misst die entstandene Kraft und gibt anschließend an den Controller ein Signal ab. Der Controller ordnet den Sensor dem Brustbereich zu und erfasst eine Nachricht und sendet diese als SMS oder Email Dazwischen ist wahrscheinlich die Programmierarbeit... Vielleicht könnt ihr euch jetzt ein etwas besseres Bild machen auf was wir heraus wollen. Und das ganze Projekt ist als Prototyp zu sehen - und nicht als fertigen Lösungssatz der in Serie geht ;) Wir MÜSSEN beispielsweise ein Budget von 180 Euro einhalten. Das bedeudet wir dürfen keine Sensoren kaufen die exakt für den Zweck vorgesehen sind da sie zu teuer werden würden. Wir können günstige Sensoren für einen kleinen "Aufprall" kaufen - müssen aber in der Dokumentation erwähnen dass wir normalerweise ... die und die Sensoren ... benötigen würden. Vielen Dank schonmal
Chr. M. schrieb: > Auch für Arduino gibt es potente HW. Selbst bei Arduino oder Arduino-kompatibel gibt es unterschiedlich leistungsfähige Prozessoren. Um nur einige zu nennen: AVR ATmega168, ATmega328, ATmega32u4, ESP8266, ARM Cortex-M3 SAM3X8E, ARM Cortex-M4 MK20DX256
Ergänzung: bitte ohne Smartphone / Apps. Wir sollen und wollen das ganze möglichst über ein Mikrocontroller hinbekommen. es soll auch eine Jacke werden. Wir haben beide kein Motorrad und müssen das Projekt am Ende auch vorstellen. Die Vorführung von einem fallenden Motorrad fällt also flach ;) An der Jacke selbst können wir vorführen... Und ja es ist ein gewagtes Thema, das wissen wir selbst. Aber wie geschrieben - es ist eine Technikerarbeit / Prototyp. Die Lehrer sollen sehen, dass wir uns ein ein Projekt eingearbeitet haben und das Problem so gut es geht gelöst haben. Selbst wenn es nicht funktioniert am Ende - die Lehrer aber ein klares Ziel erkannt haben - wäre es ok... Aber selbstverständlich versuchen wir alles damit es am Ende auch klappt.
Ergänzung 2 Uns stellen sich nur die Fragen Ist es möglich mit einem Arduino eine SMS / Email mit vorher aufgenommen GPS Daten abzuschicken und in diese Nachricht noch auzunehmen wann der Unfall passiert ist. Und eben die Auswertungen der Sensordaten so zu automatisieren damit eine fertige SMS gesendet werden kann... (Datum Ort Zeit verletzter Bereich durch Sensorpositionierung Email / SMS )
Yannik N. schrieb: > Ist es möglich mit einem Arduino eine SMS / Email mit vorher aufgenommen > GPS Daten abzuschicken und in diese Nachricht noch auzunehmen wann der > Unfall passiert ist. Und eben die Auswertungen der Sensordaten so zu > automatisieren damit eine fertige SMS gesendet werden kann... Klar, alles kein Problem. GPS-Koordinaten und Uhrzeit erhältst Du vom GPS-Modul, die SMS versendest Du über das GSM-Modul. Den Rest macht der Mikrocontroller. Soweit alles kein Problem, das schwierigste an der Aufgabe ist eindeutig die automatische Unfallerkennung.
Überlegt euch bitte auch ein Alternativprojekt. Ohne Vorbildung in Elektronik und µC werdet ihr bald feststellen dass ihr die Anzahl der angefangenen Baustellen nicht mehr überblicken könnt. Oder es wird ein(oder mehrere) Beschleunigungssensor der einfach bei G-messung >= G-grenzwert eine SMS verschickt. Als Lehrer würde ich euch das um die Ohren hauen. ;) Allerdings habe ich meine akademische Laufbahn nach 9 Jahren beendet und habe keine Ahnung was für ein Niveau bei euch so herrscht.
:
Bearbeitet durch User
Die ganze Anwendung ist doch Schwachsinn es auf die Jacke auszulagern. Neigungssensor + Beschleunigungssensor und fertig. 2,3 vorraussetzungen wann es auslösen darf und gut ist. Hier wird versucht wieder das Rad neu zu erfinden.
>Hardware verbaut >ist (wie ein Mikrocontroller) und aber auch Software genutzt wird >(Datenbanken oder Programmierung, etc.) >Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und >Programmierung angeht. Ich hoffe, eure Ausbilder erwarten nicht ernsthaft von euch Technologie einzusetzten, die ihr nicht im Lehrplan hattet. Ein bisschen Transferleistung ok, aber nicht in dem Maß.
Yannik N. schrieb: > Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und > Programmierung angeht. Das ist dann quasi so, als würde ich schnell mal eben eine Oper komponieren wollen. Nur ich weiß aber, daß ich es nicht kann. Ihr könnt euch ja mal belesen, wie ein Airbag einen Unfall erkennt. Da stecken sehr komplexe Sensorik und Berechnungen dahinter, sowie langwierige Versuche. 100 Mannjahre dürften da nicht gereicht haben.
Ich finde das ein ganz interessantes Projekt, und keinesfalls unlösbar. Vor allem besteht das Projekt aus einigen überschaubaren Teilaufgaben, also wunderbar als Gruppenarbeit geeignet. Ich würde Arduino nehmen, schon alleine wegen der Größe. Die Unfallerkennung mittels 3D Beschleunigungssensor she ich auch nicht als das große Problem. Ein oder mehrere heftige (negative) Beschleunigungen und danach das Erkennen der liegenden Jacke. Für ein proof-of-concept sollte das machbar sein. Das Auslesen des GPS und Versenden ist ein weiterer Task und durchaus machbar. Viele Grüße, Stefan
Yannik N. schrieb: > Wir sind angehende Medizintechniker (staatlich geprüfter Techniker / > Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und > Programmierung angeht. Was lernt man denn als Medizintechniker, wenn schon nichts über Sensoren, Controller oder Programmierung? Seid ihr sicher dass ihr bisher im richtigen Zimmer wart und nicht zufällig in dem für angehendende Botaniker?
Felix U. schrieb: > Wenn ihr so fragt, dann eindeutig ein Raspberry. Für ein > Notrufsignal > und Email werdet ihr ein GSM Modul brauchen. Am Raspberry wird wohl auch > ein einfacher günstiger Usb-Stick mit Linux Treibern genügen. Die > Sensoren werden sich ähnlich einfach auslesen lassen und das Debugging > wird ungleich einfacher. Klar würde man in einer realen Produktion eine > besser zugeschnittene Hardware verwenden, für ein "Proof of Concept" > lohnt das aber nicht. Würde ich nicht sagen.... Eine UART hat jeder Mikrocontroller, GSM-Module mit UART gibt es reichlich und günstig und es ist vermutlich einfacher, zuverlässiger und günstiger Wenn du schon fragst: Raspberry VS Arduino würde ich dir Arduino sagen. Arduino ist nämlich eine AVR-basierte Mikrocontroller-Plattform, Raspberry eine Linux-basierte Computer-Plattform. Für Realtime-Anwendungen sind immer Mikrocontroller die erste Wahl. OS-basierte (nicht RTOS) Anwendungen haben oft Probleme wie Zuverlässigkeit (Abstürze), Sicherheit und natürlich erhöhte Kosten. Wenn man das alle behebt ist es mehr Aufwand als gleich eine passende Plattform (Mikrocontroller ohne OS) zu nehmen. Noch besser (bzgl. Realtime, Zuverlässigkeit und Wiederverwendbarkeit) wäre natürlich eine saubere C-Implementierung auf einem beliebigen Mikrocontroller.
Als Erweiterung könntet ihr ggf. auch ein Pulsoxymeter (ab 20€) modifizieren und diese Werte (Sättigung, Puls) zusätztlich auswerten. Da finden sich doch einige "Hacks" und auch eine App-Note von Microchip in Netz. Kein oder stark erhöhter Puls spricht für einen Not-/Unfall, bei dem der Notarzt schleunigst erscheinen sollte (oder der Bestatter gemächlich auftachen), eine niedrige Sättigung ebenfalls. Unregelmäßgier Puls mit Pausen spricht für Herz-Lungen-Wiederbelebung, das einen Notarzt grundsätzlich erforderlich macht, statt "nur" Rettungssanitätern bei z.B. einfachen Knochenbrüchen. Damit könnte man schön spielen. Spontan würde ich ein solches Gerät, als Herzinfarktmonitor für Altenheime, Rentner und Pflegeinrichtungen, sogar eurem Projekt vorziehen. Pulsoxymeter an einen Mikrocontroller (z.B. ESP8266) und Meldungen ab über das WLAN an Stationsaufsicht oder Notdienst. Kostet wenig, entlastet Pflegekräfte, reduziert Folgeschäden, sowas kommt gut an. ;)
>Kein oder stark erhöhter Puls spricht für einen Not-/Unfall,
Was ist mit Schrecksekunden?
>Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und
Programmierung angeht.
Komplett also? Wie wollt ihr dann diese Aufgabe lösen? Durch fremde
Hilfe? Ich mein komplett bedeutet ja, dass ihr nichtmal die
grundlegenden Kenntisse in C/C++ besitzt und damit nichtmal Bibliothek
einbinden könnt.
Normalerweise bringt man diese Kenntnisse VOR der Arbeit mit und lernt
sie nicht während der Arbeit
Klingt mir sehr nach sehr viel zusammenkleben von fremdem Eigentum
derjaeger schrieb: >>Kein oder stark erhöhter Puls spricht für einen Not-/Unfall, > > Was ist mit Schrecksekunden? Wenn damit ein Erschrecken, ggf. mit verbundenem aussetzer eines Herzschlages gemeint ist: Das ließe sich leicht filtern, Das Herz fängt ja schnell wieder von allein an zu schlagen. Wenn damit ein Schock gemeint ist: Syptome sind u.A. ein hoher Puls und eine Hypoxie (Sauerstoffunterversorgung) im Gewebe. Beides ließe sich mit einem Pulsoxymeter messen. Bezüglich der Motorradjacke: Ebenfalls billig sind Blutdruckmessgeräte. Ein solches in den Oberarmärmel der Jacke integriert würde, wenn es nach einem Unfall (also entsprechend hohen Beschleunigungswerten/hohen aufgetretenen Kräften) regelmäßig misst, ebenfalls wertvolle Informationen über den Gesundheitszustand des Fahrers liefern und könnte ausgewertet werden.
Um die Auswertung der Sensordaten zu umgehen könntet ihr auch Taster oder auch Potis für die Simulation bestimmter Körperteile nehmen. Dazu noch die schon angesprochenen Sensoren für Herzfrequenz und Sauerstoffsättigung. Das alles an einen Arduino mit GPS- und GSM-Shield und ihr habt euch die Hardwareenwicklung und das Verarbeiten von Sensordaten gespart. Programmieren müsste ihr aber wirklich lernen um das Projekt zum laufen zu bekommen. Vermutlich ist die Programmierung (im Vergleich zu HW-Entwicklung und Signalanalyse) in diesem Beispiel noch die einfachste Aufgabe.
Eine Jacke ist aus verschiedenen Gesichtspunkten problematisch. Einfacher wäre es, (zuerst) ein Blackbox-System (unter dem Sitz + Helm + ..+ ..+) zu skizzieren und sich Strategien für Algorithmen (Notfallgrenze) zu überlegen.
Gegenfrage. Autofahren oder Birnen essen, was ist besser? Heute ist doch erst Dienstag. Kannst du nicht bis Freitag warten?
Das ist ein Vergleich wie zwischen einem Auto und einem Fahrrad. Ein Raspberry Pi ist ein kleiner Computer, der ein Betriebssystem hat oder braucht. Der Arduino ist ein simpler Microcontroller mit ein paar Bauteilen drumherum. Er ist für kleinere Aufgaben gedacht und braucht dafür viel weniger Strom/Leistung. Die Leistungsfähigkeit des Raspberrys ist um ein Vielfaches höher, aber es gibt viele Einsatzmöglichkeiten für den Arduino, wo die Fähigkeiten des Raspberrys garnicht benötigt werden und dafür die Sparsamkeit von Vorteil ist. Das "besser" bezieht sich eben immer auf den Anwendungszweck.
>der ein Betriebssystem hat oder braucht.
Bare Naked ist doch auch eine Möglichkeit
Yannik N. schrieb: > Aber ich frage mich manchmal für was Foren da sind wenn man teils > Antworten bekommen die man etwas "netter" formulieren könnte. Natürlich kann ich nur für mich sprechen, aber meiner ganz persönlichen Motivation, Dir zu helfen, ist solches Gemecker eher abträglich -- auch wenn ich ganz bei Dir bin, daß der Thread auf einige Antworten ganz gut hätte verzichten können, ohne daß ein Verlust entstanden wäre. ;-) Kurz gesagt: laß' das Gemecker, konzentrier' Dich auf die Sache. > Wir sind beide KOMPLETT unerfahren was Sensoren, Mikrocontroller und > Programmierung angeht. Dann habt Ihr eine ziemliche Einstiegshürde vor Euch. Programmierung ist eine hohe Kunst, die man nicht von heute auf morgen erlernt, und das gilt ganz besonders für Mikrocontroller mit ihren inhärenten Limitierungen. Wo zusätzliche Komplexität lauert, wie in jeder Art von Netzwerktechnologie, wird das schnell zu einer Angelegenheit, an der auch erfahrene Fachleute durchaus einige Tage, Wochen, oder sogar Monate tüfteln können. Der wunderbare und von mir besonders geschätzte Daniel Albrecht hat in einem Nachbarthread [1] seinen TCP/IP-Stack vorgestellt und sucht nach einem Projekt um diesen auszuprobieren. Vielleicht sprecht Ihr ihn mal freundlich an, ob er Zeit und Lust hat, Euch zu unterstützen? > Unsere Idee war es über einen Sensor den Sturz zu registrieren - und je > nachdem wie stark der Aufprall ist eine Art Verletzungsprognose an den > Arzt weiterzuleiten. (medizinischer Teil) > Als Beispiel: Der Motorradfahrer hat einen Frontalzusammenstoß mit einem > Auto. Der Sensor der im Brustbereich angebracht ist registriert den > Aufprall, misst die entstandene Kraft und gibt anschließend an den > Controller ein Signal ab. Der Controller ordnet den Sensor dem > Brustbereich zu und erfasst eine Nachricht und sendet diese als SMS oder > Email Die Idee finde ich gut, sehe für Euch aber einige praktische Hürden. 1.) Bei Motorradunfällen können die unterschiedlichsten Verletzungen auftreten, vor allem Kopf, Wirbelsäule und Torso sind hier gefährdet. Ihr braucht deswegen mehrere Sensoren, um potentiell letale Verletzungen von einfachen Frakturen an den Extremitäten zu unterscheiden. 2.) Die Sensoren müssen schnell genug sein und oft genug gelesen werden, um die Beschleunigungen halbwegs zuverlässig abzubilden, und um Aussagen über die Verletzungsprognose treffen zu können. 3.) Die Elektronik muss den Aufprall überleben, sonst kann sie danach schließlich gar nichts mehr versenden. 4.) Die Sensorik muß den Aufprall messen können. Es gilt: je robuster, je genauer, und je schneller ein Sensor ist, desto teurer wird er. > Wir MÜSSEN beispielsweise ein Budget von 180 Euro einhalten. Das wird spannend... ;-) De facto und unabhängig von Budget und Umsetzung gilt: ein Raspberry Pi läuft normalerweise unter einem Multitasking-Betriebssystem wie Raspbian Linux oder Windows/IoT. (Man kann ihn auch BareMetal programmieren, aber wenn Ihr das versucht, könnt Ihr Eure Promotion darüber schreiben.) Kurz gesagt: der Scheduler des Betriebssystemkerns sagt, welcher Prozeß jetzt gerade ein Zeitfenster auf der CPU bekommt (vereinfacht). Dies bedeutet leider im Umkehrschluß, daß es unter modernen Betriebssystemen wie Linux und Windows/IoT keine definierten Ausleseintervalle Eurer Sensoren geben kann, Ihr also beim Aufprall die maximale Beschleunigung wahrscheinlich verpaßt und daher keine zuverlässige Verletzungsprognose abgeben könnt. Bleiben also der Arduino oder ein ähnliches Entwicklungsboard. Die können wenigstens harte Echtzeit, wenn man es richtig macht -- allerdings nicht mit den Arduino-Libraries, sondern nur dann, wenn man eine Sprache nutzt, mit der man wirklich die volle Kontrolle über die Zeitabläufe, vulgo: die einzelnen CPU-Ticks hat. Mit einer modernen Programmiersprache wie C++ ist das sehr schwierig und erfordert enorm viel Erfahrung, mit einer weniger modernen Programmiersprache wie C ist das etwas weniger schwierig, aber immer noch nichts für Anfänger, und mit einer besonders hardware-nahen Programmiersprache wie Assembler ist das Timing zwar einfacher, dafür ist die Programmiersprache kein Zuckerschlecken -- und damit könnt Ihr kein TCP/IP und kein GSM, vulgo: keine E-Mails oder SMS versenden. Am Ende würde ich einen RasPi Zero für GSM und GPS benutzen, dazu einen Arduino Mini/Pico für die Echtzeitkommunikation mit den Sensoren; zudem noch ein preiswertes GSM- und GPS-Modul für Ortung und SMS/E-Mail, dann einen einfachen Sensor wie den 2809 von Adafruit, und dieses Konglomerat dann (Programmierheader nach außen führen!) dick eingestrichen mit einem sehr harten Zweikomponentenkleber, dann noch dick in Watte verpackt, und außenrum eine flexible oder pastöse Masse wie Silikon oder Knete in einem harten oder halbflexiblen Gehäuse wie einer Aufputz-Verteilerdose. Ach ja, so ein kleiner Modellbau-Akku mit 3,6 V für die Versorgung mit Strom und Spannung hält wohl ein paar Versuche aus, denn bei ersten Versuchen würde ich das mit einem Fallschirm von Dach werfen. Solch einen Fallschirm kann man ja aus Mülltüten bauen und dann stufenlos verkleinern... Aber, wie oben schon angedeutet: das ist nur der mechanische Teil. Der für Euch wahrscheinlich wesentlich anspruchsvollere Teil besteht darin, erst einmal das Programmieren zu lernen. Da hab' ich halt den Vorteil, daß ich das schon kann -- gut genug jedenfalls, um davon leben zu können. ;-) HTH, YMMV! [1] Beitrag "Brauche Projektidee und Hardwareempfehlung für erstes μC Projekt"
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.