Zylindrischer Hausroboter

Hallo zusammen,

so, das ist mein erster Beitrag, ich probiere mich mal darin, mein ersonnenes Projekt zu beschreiben und würde mich über Anregungen und Tipps sehr freuen.

Mein Ziel ist es, einen "Hausroboter" zu entwickeln. Das ganze soll ein Familienprojekt werden und den Großvater (handwerklich) und die 10jährige Tochter (gestalterisch, spielerisches Ranführen ans Programmieren) einbinden.

Meine persönlichen Erfahrungen sind eher im unteren Bereich anzusiedeln. ;-) Daher ist immer auch ein bisschen die unterschwellige Frage: Übernimmt man sich mit so einem Projekt schon, oder ist gerade die modulare Vorgehensweise (siehe unten) eigentlich ganz gut und sinnvoll, um die einzelnen "Lektionen" zu lernen. Ich bin einigermaßen flexibel, was den Softwareteil angeht (immer privat und beruflich mit IT in Berührung gewesen, brauchbare Kenntnisse in C/C++ (etwas eingestaubt), Java, Javascript, Perl, PHP, etc.. Python kann ich zumindest einordnen und Code lesen und verstehen und sehe mich auch in der Lage, das soweit aufzumöbeln, wie ggf. für die Programmierung der Logik des Roboters nötig). Ich habe letztens meine erste Raspberry Pi Erfahrungen gesammelt (habe ein Busy Light nachgebaut, welches von Microsoft Teams den Anwesenheitsstatus abfragt und dann auf eine LED-Phat überträgt und so meiner Tochter vor dem Home Office-Raum anzeigt ob ich verfügbar (grün) oder busy (rot) oder away (gelb) bin). Elektrotechnik beschränkt sich auf den Kosmos-Kasten in der Kindheit und Einlesen in den letzten Wochen. ;-)

Mein Ziel ist das folgende: Einen Roboter zu bauen, der auf einer vermutlich runden Chassis aufgebaut ist und als Grundform zylindrisch ist (ein bisschen wie R2D2, ohne den Anspruch zu haben, diesen nachzumodellieren). Als "Korpus" schwebt mir da in der Tat ein Drahtgeflecht-Papierkorb nach diesem Muster vor: https://www.amazon.de/-/en/Relaxdays...843686&sr=8-13 Die Außenhülle kann durch die Tochter später laminiert und gestaltet werden.

Ich möchte gerne modular vorgehen und die folgenden Fähigkeiten in den beschriebenen Ausbaustufen ergänzen:

1. Ausbaustufe: Grundstruktur (Chassis noch ohne Verkleidung) und Vorwärts/Rückwärtsbewegen sowie Kurven. Dazu sollen zwei Räder mit Motoren verbaut werden sowie 1x Gleitkugel (also ein "Tricycle"-Aufbau). Steuerung zunächst per WLAN, entweder einfach über Terminal Session oder je nach Lust und Laune mit einer einfachen Web-Bedienoberfläche. Fahrten natürlich innerhalb der Wohnung nur langsam notwendig. Das Gewicht des ganzen Roboters sollte m. E. künftig 5 kg nicht übersteigen.
2a. Ausbaustufe: Ergänzen der zylindrischen Verkleidung (also das Drahtgepflecht-Papierkorbs o. Ä.) sowie Anbau erster Sensoren um Objekte im Fahrtweg festzustellen (Ultraschall Sensor, Infrarot Sensor, o. Ä.) sowie ein einfaches Display um Gemütszustände auszudrücken (kleines OLED, oder LED-Matrix, o. Ä.).
2b. Ausbaustufe: Weitere Pheriperie - Geräusche wahrnehmen (Mikrofon) und darauf reagieren, Äußerungen ausgeben (Lautsprecher), Dinge sehen (Kamera) (im "Gesichtsbereich"des Roboters, als vorne oben im Zylinder)
3. Ausbaustufe: Sprechen, Sprache verstehen (Richtung digitaler Assistent als Alexa-Ersatz)
4. Ausbaustufe: Autonome Navigation in der Wohnung, Autonomes Verhalten (Begrüßen wenn er Leute sieht o. Ä.), Smarthome-Geräte kontrollieren
5. Ausbaustufe: Ladestation mit autonomem Laden (hier bin ich noch unsicher, ob wir das wollen und ob das "sicher" zu bewerkstelligen ist. Ich habe großen Respekt vor LiPos)

Meine große Frage ist aktuell, mit welchen Komponenten beginne ich mit Stufe 1, so dass ich uns für die folgenden Stufen nichts verbaue.

Als Basis möchte ich nach Möglichkeit wieder einen Raspberry (Zero? Oder doch eher größer?) verwenden. Ansonsten bin ich gerade recht viel auf joy-it.net unterwegs und bin der Meinung, dass hier recht viele sinnvolle Komponenten zu haben sind. Aber ich scheitere ein wenig an der Auswahl, etwa der Motoren. Und dann auch die Frage der Motorenansteuerung. Brauche ich für das obenbeschriebene Szenario einen separaten Microcontroller (die Anfängerfrage schlechthin?) und welcher ist am besten mit dem RPi kombinierbar, ohne dass ich mir eine Sackgasse baue. Hier im Roboternetz habe ich zwar viele Infos dazu gefunden - habe aber das Gefühl, dass die "Wiki"-Texte oft viele Jahre alt sind (keine Kritik) und bin mir dann nicht sicher, ob die Infos so noch gelten.

Halter ihr den Ansatz grundsätzlich für machbar? Ich möchte ungern erst ein "Wegwerfprodukt" als Zwischenlösung zum Lernen bauen, sondern eben lieber modular aufbauen. Ich bin der Meinung, dass die beschriebene Form eine recht einfach realisierbare Form ist, die auch im Innenraum des Zylinders viel Platz bietet. Ich fand es bei der Recherche erstaunlich, dass ich wenig bis keine vergleichbare Projekte gefunden habe.

Danke für Einschätzungen, Tipps, Warnungen, Teile-Empfehlungen etc! :)

Schönen 4. Restadvent und Grüße

Patrick

Wie viel Zeit möchtest du denn investieren und wie hoch ist dein Budget?

Machbar ist das schon, wenn du ein bisschen Erfahrung mit den Raspis hast, denke ich.
Allerdings solltest du wissen, dass ein Raspi für Steueraufgaben nicht unbedingt optimal ist.
Ich würde die Steuerung nen Arduino machen lassen (die können das bei weitem besser), und den Pi zum rechnen (erst mal unnötig) und die WLAN-Steuerung nehmen.

Was ich für nicht optimal halte sind das Antriebskonzept und auch der Papierkorb.
Antrieb: _ich_ würde es mit drei Motoren und Allseitenrädern machen. Da kann man beispielsweise Schrittmotoren verwenden, und in irgendeiner Ecke festfahren gibts nicht mehr.
Bei einem Zweirad-Antrieb kann man das, wenn man die Anordnung gut wählt, zwar auch hinkriegen, aber dann wirds auch etwas kippelig. Wenn sowas auf dem Punkt drehen soll, müssen die beiden Räder mittig sein.
Ausserdem erspart man sich bei Schrittmotoren zusätzliche Odometrie-Sensoren (ohne die ein vernünftiges manövrieren in ner Wohnung oder so kaum möglich sein wird, irgendwoher muss ja der Papierkorb wissen, wo er ist).
Grundsätzlich ist deine Lösung zwar deutlich einfacher, aber auch eingeschränkter.

Wegen dem Papierkorb: du wirst Aussparungen brauchen, du wirst jede Menge Montagemöglichkeiten brauchen, das kriegt man zwar mit dem Drahtgitter schon irgendwie hingefrickelt, aber was ne Bastelei....wenn da sowieso jemand ein Gehäuse "basteln" will, wieso nicht einfach nur ne tragende Struktur innen, die alles trägt?
Ich würds mitm 3D-Drucker machen (falls du einen hast). Da kann man auch gleich die nötigen Befestigungen vernünftig lösen.

Und: WLAN heisst Funkwellen. Die müssen also durch das Drahtgitter durchkommen- je nachdem, wie fein es ist, kannst du das entweder völlig vergessen, oder es wird schlecht funktionieren (zumal die Pi's im Funkbereich keine Heldentaten vollbringen).

Wegen dem Zero: ich spiel auch ganz gerne mal mit denen (...billiger als'n Arduino...), aber die Rechenleistung ist auch begrenzt. Ein gut Teil geht schon fürs System und das Interface (ich arbeite eigentlich immer mit VNC und nem virtuellen Bildschirm, weils so schön praktisch ist) flöten.
Bisselwas schafft der schon noch, aber die Dinger haben halt ihre Grenzen. Spätestens beim Kamerastream in HD wird es dann eng, da läuft meiner schon mal auf 100% Last.
Besser wird es, wenn man auf den Desktop verzichtet-aber wer will das schon (ich jedenfalls nicht).
Den 3er (ich hab den B oder 3+ oder sowas) hab ich noch nicht wirklich in die Knie bekommen.

Wenn du vorgehst, wie _ich_ es machen würde (nämlich für die Sensoren und die Antriebssteuerung einen Arduino nehmen, da reicht schon ein ganz billiger ProMini oder Nano), wirst du nur mit wenigen Leitungen zwischen Pi und Arduino auskommen, du kannst also erstmal nen Zero nehmen, und den später ggf, austauschen.
Falls du vor hast, später mit vielen Sensoren zu arbeiten, wäre vielleicht ein Arduino Mega2560 (gibts auch Clone für wenig Geld) die bessere Wahl- die haben abartig viele IO-Pins, sowie drei serielle Schnittstellen (UART). Kostet ein bisschen mehr, aber kann auch so richtig was.

Mein Freddie hat nen Arduino Nano als "Fahrer"- der handlet zwei Motoren, zwei Lichtschranken-Odometer(die per Interrupts überwacht werden->wichtig), überwacht den Akku, vier weitere Lichtschranken als Hindernis-Sensoren, liest ein Joypad aus (fünf Taster), und kann nebenher noch einiges über den I2C-Bus erledigen.
Mehr wirds dann aber auch nicht- der ist Pinmässig ausgereizt.
Für die weiteren Sachen hab ich derzeit da auch nen Pi Zero drauf, an der Kommunikation zwischen den beiden sitz ich noch (I2C kann der Pi auch nicht ganz so, weil er das nicht hardwaremässig kann, ich habs z.B. nicht geschafft, den als Slave laufen zu lassen).

Zitat:

---

Übernimmt man sich mit so einem Projekt schon, oder ist gerade die modulare Vorgehensweise (siehe unten) eigentlich ganz gut und sinnvoll, um die einzelnen "Lektionen" zu lernen.

---

Alleine über das Thema "Navigation eines Roboters" wurde schon unzählige Doktorarbeiten geschrieben. Aber lass' dich davon nicht erschrecken. Andere haben das auch hinbekommen. Ich denke, Du hast die wichtigste Regel schon befolgt: Teilen und beherrschen! Du hast dein Projekt in Teilschritte zerlegt. zerlege jeden Teilschritt in kleine, weitere Sub-Projekte und diese nochmals in Sub-Sub-Projekte, so dass Du quasi eine Anzahl X an Tagesaufgaben erhältst. Dann bleibt das Ganze übersichtlich und Du siehst immer wieder Teilerfolge. Mit einem Mindmapping-Programm, wie z.B. Freemind, kannst Du übersichtlich das Gesamtprojekt in Teilprojekte zerlegen.

Räder

Als Hinweis, für die Überlegung. Es waren ja nur zwei Räder im Spiel. Ich hatte eine ähnliche Konstruktion, wollte aber, dass das Gerät sicher steht (kein Hilfsrad benötigt) und problemlos geradeaus fährt.

https://youtu.be/-CJvaRZ4xA4

Auch ohne elektronische Steuerung fährt das praktisch schnurgerade, was allein bei nur einem Rad links und rechts nicht selbstverständlich ist. Drehen kann so was, wenn auf einer Seite die Räder entgegengesetzt drehen. Beide Motoren einer Seite werden wie ein Rad behandelt und gesteuert.

---

Zum Thema Motoren, da war ich auch mal auf der Suche. In diesem Thread. Und hatte dazu noch mehr gefunden.


Liebe Grüße

Hallo zusammen,

vielen Dank für die Antworten schon einmal!

Also ein finites zeitliches und finanzielles Budget gibt es nicht. Für mich ist ein Stückweit auch der Weg das Ziel und für meine Tochter soll der Lerneffekt auch sein, dass die ganzen Gadgets, die sie so kennt, nicht einfach so vom Himmel fallen, sondern da sehr viel Detailarbeit drin steckt.

Dennoch mal als grobe Rahmen: Ich würde gerne recht "zügig" (innerhalb einiger Wochen, sprich Stunden) mal die Ausbaustufe I erreicht haben. Eine Chassis, die man ferngesteuert bewegen kann. Für das Gesamtprojekt (und natürlich wird es unterwegs neue Ideen geben oder bestehende Ideen weisen sich als nicht sinnvoll heraus etc.) würde ich mich freuen, wenn wir im November soweit "fertig" sind, dass der Roboter eine tragende Rolle verkleidet als Geist bei unserer Halloween-Geisterbahn einnehmen kann. ;-) Vom finanziellen Budget her: Ich finde, viele Einzelteile sind erstaunlich günstig. Der ganze Spaß sollte denke ich mal vom groben Rahmen her im dreistelligen Bereich bleiben (können).

Zur Steuerung: Ich habe tatsächlich noch nicht abschließend verstanden, warum der Raspberry Pi hierzu nicht ausreicht. Klar - die Anschlüsse reichen nicht, aber dafür gibt es ja, wenn ich es richtig sehe, entsprechende Extensions. Aber neben den Anschlüssen, welche Vorteile verschafft mir ein separater Mikrocontroller wie der Arduino Mega2560 konkret - dann ja mit dem "Nachteil" einer komplizierteren Architektur. Könnte man dann sinnvollerweise den RPi und Mega2560 per USB verbinden um die Kommunikation im Betrieb zu gewährleisten?

Weiterhin habe ich die Vorbehalte gegenüber dem Antriebskonzept, bzw. die relevanten Vorteile eines dreimotorigen Konzepts mit 3 omnidirektionalen Rädern noch nicht ganz verstanden. Ein auf der Stelle drehen und omnidirektionale Bewegung finde ich gar nicht so wichtig. Wenn der Roboter sich in eine Ecke verfährt, kann er doch einfach rückwärts wieder rausfahren? Dennoch hatte ich aber auch schon solch ein Chassis im Fokus gehabt. Hier gibt's eins mit drei Allseitenrädern inkl. Motoren. Gibt es Einwände gegen so ein Produkt? Kommt aus China und scheint mir recht teuer, aber mir gefällt es grundsätzlich ganz gut: https://www.amazon.com/SZDoit-Premiu...cx_mr_hp_atf_m

Den verlinkten Papierkorb für 3,90 EUR habe ich mir übrigens mal bestellt und werde mal mit meinem vorhanden RPi Zero prüfen, wie sich das WLAN Signal im Innenraum des Korbs verhält.

VG

Patrick

Die von dir verlinkte Plattform auf Amazon finde ich nicht teuer. Immerhin sind dort 3 Motoren mit Encoder vorhanden. Ich finde, die Plattform ist viel zu klein. Mit etwas mehr als 20cm im Durchmesser kannst Du nicht wesentlich in die Höhe gehen, weil das Teil sonst umkippt. Ich weiß nicht genau, welche Größenvorstellungen Du hast, aber meiner Meinung nach sollte eine solche Plattform doppelt so groß sein, damit Du nicht im Platz zu sehr eingeengt bist.

VG, Jürgen

Hhmhh - der Papierkorb, der ja letztlich die Zylinderform vorgibt, hat einen Durchmesser von 23 cm und eine Höhe von 24 cm. Zumal die meisten zumindest vorgefertigen Chassis in der Größenordnung oder kleiner zu sein scheinen. Man könnte die Platte natürlich selbst anfertigen. Grundsätzlich finde ich die Größe aber erst einmal "in Ordnung" und würde denken, da ist erst einmal reichlich Platz drin (und dran - nicht alles muss ja drinnen "leben" - ich könnte mir später mal vorstellen, Akkus außerhalb zu befestigen). Zumal größer ja prinzipiell auch immer schwerer heisst. Aber das sind natürlich alles nur subjektive Einschätzungen meinerseits ohne Erfahrung.

Bleibt bei der von Amazon verlinkten Plattform die Frage, ob die Motoren was taugen oder ob man die dann eh gegen "bessere" austauschen müsste.

Bei den Omni-Rädern kennt sich @Inka gut aus. Der baut damit. So weit ich das verstanden habe, sind die vor allem für gerade Böden geeignet. Das angestrebte Ziel soll aber sicher sein, dass der Roboter auch über Hindernisse fahren kann, zumindest über kleine Schwellen.

Dieses von mir entworfene Chassis hat eine Größe von etwa 10cm im Durchmesser. Die Radgröße soll auch bedacht werden, ich würde bei einem größeren Chassis auf einen Raddurchmesser von bis zu 5cm setzen (nicht unter 3cm).


https://www.youtube.com/watch?v=sNDg8XuH5gE


Der Drehpunkt dieses Chassis befindet sich in der Mitte, so war das gedacht. Im Video nicht zu sehen ist, dass es nur mit angeschlossener Batterie fährt (Kroko-Klemmen zu den Motoren, alle an derselben Batterie); um zu sehen, ob die Konstruktion generell für das geplante Vorhaben taugt. Wichtig war für mich vor allem, dass das Gerät von Raum zu Raum fahren kann und über Teppiche, so gut es geht. Dinge, die man vorher bedenken muss.

Was die mehreren Controller angeht, das kann man machen, muss man aber nicht. Wenn man mit Getriebemotoren und analoger Motorsteuerung arbeitet (also keine Schrittmotoren, wo man jeden Schritt kontrolliert), ist das eigentlich kein Problem. Die Motortreiber werden aktiviert, das Teil fährt in eine Richtung, bis eine Drehrichtungsumkehr oder ein Stop erfolgt. Das kann man mit einem Arduino UNO bis MEGA oder sicher auch mit einem Pi machen. Zur Leistungsfähigkeit der drei genannten Dinge und dem geplanten sonstigen Zweck kann ich nichts sagen, da fehlt mir die Erfahrung damit.

Gruß
Moppi

Ein Raspi ist nicht Echtzeit-fähig, da er eher ein PC ist als ein Steuer-Controller.
Der kann kein Multitasking.

Um beispielsweise einen Motor anzusteuern, brauchst du meistens eine PWM. Das kann ein Raspi zwar, aber das wird rein per Software gemacht, während Steuer-Rechner (wie sie auf den meisten Arduino-Boards verbaut sind) das alles in Hardware machen.
Wenn du bei einem Arduino eine PWM auf irgendeinem Pin ausgibst,dann macht der das im Hintergrund so lange weiter, bis er den Befehl bekommt, damit aufzuhören.
In der Zwischenzeit kann man alles Mögliche treiben, das funktioniert so auch mit mehreren Pins gleichzeitig.
Du kannst ihn also munter irgendwas rechnen lassen, ohne dass die PWM davon auch nur im Geringsten beeinflusst wird (die Pins tun einfach das, was ihnen zuletzt gesagt wurde, im Hintergrund weiter).
Das ist beim Raspi nicht so, da das alles in Software gemacht wird.
Immer, wenn der nen neuen Befehl bekommt, hört er mit dem vorherigen (erstmal) auf. Das wird zwar in der Software gut überspielt (in vielen Fällen merkt man davon gar nichts), kann einem aber auch auf die Füsse fallen.

Auch die I2C-Schnittstelle betrifft das: die gibts zwar, ist aber eingeschränkt. Ich habs nicht geschafft, einen Pi zum I2C-Slave zu machen, weil das schlichtweg nicht implementiert ist.
Die meisten Arduinos haben ausserdem einige analoge Eingänge. Damit kann man beispielsweise einen Thermistor (temperaturempfindlicher Widerstand) ganz einfach einlesen, oder einen Fotowiderstand.
Das kann ein Pi _nicht_, ohne weitere Hardware, da er keinen AD-Wandler hat.

Mit einigen Tricks und Umwegen geht sowas durchaus auch mit nem Raspi (mit Einschränkungen, die man je nach Szenario merkt oder auch nicht)- aber mit einem Arduino ist halt manches deutlich einfacher, weil die solche Steuer-und Messaufgaben "einfach so" können.

Falls du es mit nem Pi machen willst: https://hackaday.io/project/25092-ze...rted-fall-2018
Da hast du nen recht guten Einstieg, wirst aber andere Motoren und Motortreiber brauchen. Diese TT-Motoren da reichen für den kleinen gradenoch, für was grösseres sind die zu schwach.

Wegen den zwei Motoren: zwei geht auch, klar- aber drei wäre die elegantere Lösung.

Bin dann erst einmal auf Shopping-Tour gegangen gestern und habe folgende Teile bestellt:

Raspberry Pi 4 Model B, 4GB RAM + Netzteil/SD-Karte
Oben verlinkte 3x omni wheel Chassis incl Motoren
Adafruit DC & Stepper Motor HAT für Raspberry Pi
seeed Grove - Base HAT für Raspberry Pi
2 günstige seed Grove Sensoren zum Probieren
Bisschen Kleinkram

Mal sehen, wie weit ich damit komme für die ersten Gehversuche. ;-)

Schöne Weihnachten!

Sieht nach einem ganz guten Einstieg aus- unter der Voraussetzung, dass Buster wenigstens auf dem 4er anständig läuft.
Auf meinem 3er und auch den Zeros wars ne Katastrophe.

Was du aber noch brauchen wirst ist eine anständige moblie Stromversorgung für den Pi. Netzteil ist in nem mobilen Roboter nich so optimal.

die stromversorgung, sprich akku, ist letztendlich immer ein kompromiss zwischen der roboterform, der gewollten aktionsdauer und dem was auf dem markt zu bekommen ist...

Hier der ministaubsauger (erstmal nur das fahrgestell)

https://youtu.be/cuWUW7My57U

Anhang 35680 Anhang 35681

Moin zusammen,

hier mal zum neuen (frohen) Jahr ein Update.

Über die Feiertage waren die diversen bestellten Teile langsam eingetrudelt. Ich hatte dann gleich auch noch einige weitere Seeed Grove Sensoren/Module bestellt, da die einzeln ja doch recht günstig sind. Somit habe ich nun von Grove ein Mikrofon, einen Speaker, ein Accelerometer, eine LED-Matrix und eben den US-Sensor vorliegen. Zusätzlich auch das Kameramodul mit Infrarot (hauptsächlich, weil es so toll nach Roboter aussieht, um ehrlich zu sein).

Dann haben wir im neuen Jahr den Zusammenbau begonnen und ich bin überrascht, wie gut das soweit funktioniert hat. Wir haben die erste oben beschriebene Ausbaustufe und etwas mehr ohne größere Rückschläge hinbekommen. Die Montage des Chassis war schnell gemacht. Beim wenigen erforderlichen Löten (nur der Motor Controller) musste ich zunächst ein wenig üben (das letzte Mal in der Schule, ewig her), hat aber am Ende gut geklappt. In den Abendstunden hab ich mir jeweils Python angelesen und dann nach erfolgreicher OS-Installation auf dem Pi und der Montage die ersten Programme erstellt.

Damit haben wir eine fertige Chassis, die sich (aktuell natürlich weder autonom, aber auch noch nicht über eine hübsche Web Oberfläche, sondern per Remote Desktop aus der Python IDE Thonny heraus) in 4 Richtungen bewegen kann (Vor, Rück, Rechts, Links), die sich in beide Richtungen im Kreis um die eigene Achse drehen kann, die bei Hinderniserkennung nach vorne (bei 20 cm) anhält, einen Signalton ausgibt und eine Info über das Hindernis ins Terminal schreibt.

Das Bild ist nicht ganz aktuell, mittlerweile sind mehr Sensoren etc. angebaut:

Anhang 35729

Da das Ausprobieren am Netzkabel doch etwas hinderlich ist, habe ich am Wochenende eine ausreichend dimensionierte Powerbank ergänzt für den Raspberry. Die Motoren werden eh von 6 AA-Batterien seperat bestromt. Beides (die Batterien und die Powerbank) liegen zumindest fürs Experimentieren einigermaßen komfortabel auf Etage 1 des Chassis, während die weiteren Bauteile größtenteils auf Etage 2 angebracht sind. Später möchte ich die Energiezufuhr am Korpus (ggf. außen als "Rucksack") befestigen. Ob wir bei der Powerbank bleiben, weiß ich noch nicht. Blöd wäre ja bei wirklich einigermaßen autonomem Betrieb, dass der Pi einfach irgendwann ausgehen würde.

Weitere aktuelle To Dos sind die Bedien und Info-Weboberfläche sowie die Befestigung des Korpus aka Papierkorbs. Zu letzterem haben wir Opa eingebunden und er ist am Thema dran...

Aktuell habe ich folgende Fragen/Problemchen:

Ich scheitere noch etwas an der wackelfreien und zukunftssicheren Befestitung der Komponenten an der Chassis. Die verfügbaren Löcher in der Chassis passen ganz gut für M3 Schrauben. Für den Raspberry braucht es M2.5 und die Grove-Elemente M2. Außerdem müssen manche Sensoren ja im 90%-Winkel anbegracht werden. Irgendwie fehlt es mir da an den richtigen Adaptern, Passtücken um das sinnvoll zu verbinden. Und dann wäre auch die Frage, wie man da am geschicktesten mit Unterlegscheiben arbeitet, an welchen Stellen machen die Sinn, damit sich die Schräubchen im Betrieb nicht ständig lösen. Winkel im Baumarkt und Online sind selten oder nie mit M2-Löchern zu finden, da man wohl in der Regel eher Schränke und Tische damit verbindet. ;-)

Der Lautsprecher kann im Prinzip über PWM oder Digital GPIO angesteuert werden. PWM habe ich nicht zum Laufen bekommen, über GPIO bekomme ich einfache "Buzzer"-artige Töne hin. Hat jemand Erfahrung damit, einen Lautsprecher, der nicht über die normale Audio-Schnittstelle des Raspberry verbunden ist, zur Wiedergabe von Audio-Dateien zu verwenden? Mir geht es ja letztlich um Sprachausgabe. Die kann ruhig blechern klingen, aber nur Buzzer-Töne reichen nicht. Ich habe dieses Teil: https://www.seeedstudio.com/Grove-Sp...us-p-4592.html Lautstärke ist erstaunlich gut, dafür dass es kein mit externer Stromversorgung betriebener aktiver Speaker ist..

Wenn Du keine Winkel hast, nehm' ein Stück Holz und bohr Löcher rein. Damit metrische Schrauben funktionieren, kannst Du ab M3 Rampa-Muffen benutzen: https://www.rampa.com/de/de/hartholz...messer-5_x_0_5

Kleine Schrauben bekommst Du im RC-Modellbau, z.B. beim Himmlischen Höllein: https://www.hoelleinshop.com/futaba-...=16007&p=16007

Bez. der kleinen Schrauben in den großen Löchern: Kauf die ein Set Unterlegscheiben und Zahnscheiben, z.B. hier: https://www.amazon.de/Unterlegscheib...2s9dHJ1ZQ&th=1 und hier https://www.amazon.de/Zahnscheibe-Si...ps%2C67&sr=8-6.
Dann machst Du eine Zahnscheibe auf die Schraube und dann Unterlegscheiben, bis die Auflagefläche groß genug ist, also in der Reihenfolge auf die Schraube schieben: Zahnscheibe, kleine Unterlegscheibe, große Unterlegscheibe.
Vorsicht: Baumärkte fangen erst bei M3 mit Schrauben an. Kleinere Schrauben und Unterlegscheiben bekommst Du hier: https://modellbauschrauben.de/

VG, Jürgen

Hi rhino, Kompliment für das Projekt und DEN Arbeitsfortschritt.

Zitat:

---

.. Hat jemand Erfahrung .. Lautsprecher .. zur Wiedergabe von Audio-Dateien zu verwenden? ..

---

Mit dem WTV020 (klick für´n Video) habe ich meinem archie "sprechen" beigebracht , also abspielen von vorher aufgenommenen Audiofiles. Ne simple Ansteuerung mit Zahlen bis 255 in einem I²C-ähnlichen Protokoll wählt einen von den entsprechend benannten Audiofiles aus. Auch Befehle wie z.B. Lautstärke 1..8 oder so sind möglich. Also eher eine Art Abspielmaschine . . . Ob und wo man das (noch) bekommt weiß ich aber nicht. Vor allem die notwendigen, etwas klein geratenen (alten) Micro-SD-Karten sind selten geworden.

Es gibt Audio-(MP3)-Module, da kann man direkt einen Lautsprecher anschließen. Nicht größer, als das Verstärkerplatinchen (Grove - Speaker Plus). Mit Micro-SD-Karte für die MP3-Files. Anonsten weiß ich, dass man Sprachausgabe auch per PWM machen kann. Da gab es in den frühen 90gern mal ein programm für den PC, zur Ansage der Uhrzeit. ich glaube, das basierte auch auf PWM. Die PCs hatten ja richtige kleine Lautsprecher verbaut. Man konnte das sogar gut verstehen. Hier ist auch so ein Thema.

Hier noch was zum Thema DA-Wandlung per PWM.

was schrauben betrifft, in china gibt es ja bekanntlich alles. es kann sich aber im laufe der zeit ansammeln:
Anhang 35730

Danke für die Tipps bzw. kaskadierender Unterlegscheiben zur Überbrückung bei unterschiedlichen Schrauben/Lochgrößen. Das werde ich so ausprobieren.

Hinsichtlich Audio passen die Vorschläge nicht zum geplanten Vorgehen. Mein Ziel ist es nicht, zuvor aufgenommene Audiofiles abzuspielen. Mein Ziel ist es, Konversationen vergleichbar zu Sprachassistenten wie Alexa, Siri etc. zu führen um ihm beispielsweise mitzuteilen, wo er hinfahren soll oder natürlich auch einfach "Spaß"-Konversationen für die Kids.

Nachdem ich kurzzeitig mit dem Gedanken gespielt hatte, die nötigen Machine Learning Modelle irgendwie auf dem Raspberry laufen zu lassen, habe ich wegen der Komplexität (und letztlich nicht nur MEINER sondern auch der begrenzten Kapazität des Pi) davon wieder Abstand genommen.

Mein aktueller Plan setzt stark auf Cloud Services und sieht wie folgt aus:

1. Bei aktivem Monitoring (ggf. getriggert durch weitere Sensoren wie den Ultraschallsensor, d.h. nur Monitoring, wenn jemand "in der Nähe" ist, der Roboter also schon die physische Präsenz von jemandem festgestellt hat) werden die Geräusche fortlaufend im 5-Sekunden Rhytmus daraufhin untersucht, ob es sich um allgemeine Geräusche oder Sprache handelt. Das wäre noch lokal umzusetzen, also auf dem Raspberry. Open Source Libs in die Richtung hatte ich schon gefunden. Muss ich nur noch wiederfinden...
2. Bei erkannter Sprache wird der Audio-Ausschnitt an einen Cloud Service gesendet, der das Gesprochene in Textform zurückliefert (aktuell gehe ich von der Microsoft Azure Cloud aus - für den Privatgebrauch ist da genügend Volumen kostenfrei zum Spielen enthalten).
3. Der Textstring wird in einem weiteren Schritt mit einem weiteren Cloud Service (ggf. auch MS Azure, oder SAP Conversational AI, damit habe ich beruflich Erfahrung, auch kostenfrei nutzbar ohne Limit für Privatgebrauch) interpretiert, d.h. Intents und Sentiments werden gelesen und zurückgeliefert.
4. Der Roboter kann dann die Aktivitäten ausführen, die auf die Intents gemapped sind und/oder eine Sprachantwort zurückgeben.
5. Bei Sprachantwort wird der Text wiederum an die MS Azure Cloud zur Umwandlung in ein auszugebendes, gesprochenes Audio-File gebeben.
6. Das Audio-File wird auf dem Roboter ausgegeben.

Irgendwo zwischen Schritt 1 und 3 muss noch das Triggerwort ("Hey, Kurt!") eingebaut werden, so dass der Roboter nicht alle unsere Gespräche mühsam verarbeiten muss.

Im Praxistest wird sich zeigen, wie sich der Datenaustausch mit multiplen Cloud-Services verhält und ob die Antwortzeiten entsprechend ausreichend sind. Siri muss aber auch manchmal 2-3 Sekunden "überlegen", bis eine Antwort kommt...

Eigentlich brauche ich also einen Lautsprecher, der Schritt 6 kann (kann das der einfache Lautsprecher an der PWM-Schnittstelle leisten?) und ein Mikrofon, welches das ständige Monitoring liefert.

Zitat:

---

Zitat von rhino25782

Eigentlich brauche ich also einen Lautsprecher, der Schritt 6 kann (kann das der einfache Lautsprecher an der PWM-Schnittstelle leisten?) ...

---

Diese Frage sollte hinreichend beantwortet sein, mitsamt Hintergrundinformationen warum und wie das funktionieren kann. Nochmal zur Erinnerung:

Zitat:

---

Zitat von Moppi

Hier noch was zum Thema DA-Wandlung per PWM.

---

Da das offenbar alles fix und fertig sein soll und am besten, ohne viel Arbeit um das Wie und Warum zu investieren, würde ich einen DA-Wandler-Baustein suchen, der zusätzlich angeschlossen wird und ein sauberes Signal liefert. Zum Beispiel sieht das sehr brauchbar aus, ist ein kleines Break Out und funktioniert offenbar. 12Bit sollten ausreichend sein. Anzusteuern ist der MCP4725 per I2C, und auch noch programmtechnisch in einem sehr übersichtlichen Rahmen. Da hat man ein Analogsignal im Bereich 0 bis 5V (wie im Beispiel), was schon ganz anständig ist. Das Signal müsste man wohl über einen Kondensator (10µF) auskoppeln, dann an einen Spannungsteiler (Poti, 10k gegen GND z.B.; die 10k müssen zwischen Kondensator und GND liegen) führen und von da (mittlerer Spannungsteilerabgriff) an einen (Deinen) Verstärker. Ganz ohne experimentieren wird's wohl aber nicht gehen.

Gruß
Moppi

Hallo zusammen,

fast 9 Monate später, wird es mal wieder Zeit für ein Update - damit das hier nicht zu einem dieser verwaisten Threads verkommt, die mal angefangen, aber nicht weitergeführt werden. ;)

Beim Roboterprojekt hat es in der Tat einige Verzögerungen (musste zwischendurch kurz heiraten) und auch Rückschläge gegeben (ich habe mir einmal die SD-Karte versaut und musste von vorne beginnen, hatte zum Glück eine Sicherung des bis dahin entwickelten Python Codes und wir mussten eine ganze Zeit frickeln, bis wir den Papierkorb wackelfrei und sicher am Chassis befestigt hatten), aber mittlerweile nimmt der Roboter (er heisst Kurt) echt Form an. Natürlich steckt weiterhin noch viel Arbeit drin, insbesondere in der weiteren Programmierung.

Mal eine kurze Beschreibung, wie der aktuelle Entwicklungsstand ist:

- Die weiter oben erwähnte, zweigeschossige, dreieckige Metallchassis mit den drei omnidirektionalen Rädern und drei 9V DC Motoren bildet weiterhin die Basis des Projekts.
- Das "Gehirn" ist der oben bereits erwähnte Raspberry Pi 4 - bisher habe ich noch keine Verwendung für einen seperaten Microcontroller zur Motorsteuerung gefunden.
- Auf dem Raspberry PI sind die folgenden HATS - in der Reihenfolge - im Einsatz:
* Adafruit Motor HAT um die drei Motoren zu kontrollieren. Die 9VMotoren werden aktuell einfach durch 6 x 1.5 AAA Alkaline Batterien angetrieben, das gefällt mir noch nicht. Siehe unten -> Offene Themen
* Seeed Grove Base Hat - zur Anbindung von Sensoren. Aktuellen sind aus dem Grove-Universum drei US-Sensoren (unterhalb der Chassis in alle drei Richtungen montiert), ein Kompass, ein Accelerometer montiert. Richtig nutze ich bisher nur einen US Sensor. Mit der Genauigkeit ds Kompass und des Accelerometers bin ich noch nicht zufrieden, hatte aber auch noch nicht genug Zeit, mich wirklich damt zu beschäftigen.
* PiJuice zur Stromversorgung. Den PiJuice kann man als Uninterrupted Power Supply verwenden, ich habe aktuell noch testweise eine 5000 mah Li-Ion Batterie angeschlossen (ebenfalls siehe unten -> Offene Themen). Man kann hier dann einfach zum Laden oder für den Netzbetrieb den PiJuice über microUSB mit Strom versorgen, ohne dass zwischendurch der Pi ausgeschaltet werden müsste (wie bei der alten Lösung mit simpler Powerbank). Zusätzlich bietet der PiJuice Status-LEDs für die Stromversorgung und eine User-programmierbare LED, mit der ich den Roboterstatus anzeige (Betriebsmodi) und mehrere Buttons und eine Buttonschnittstelle. Da die Buttons durch den Papierkorb nicht mehr erreichbar sind, habe ich als "Masterswitch" einen simplen Button unterhalb der Chassis, bequem mit der Hand zu erreichen, montiert und verbunden. Damit kann ich den Raspi hochfahren (und das kurt.py Script mit dem Bootvorgang starten lassen) sowie runterfahren (long press) oder hard reset (very long press) initieren. Gefällt mir in Summe sehr gut!
* Seeed ReSpeaker 4mic Array. Das Array funktioniert deutlich besser zur Audio-Aufnahme als das zuvor verwendete USB Mikrofon. Zusätzlich ist eine Richtungserkennung möglich, damit möchte ich implementieren, dass der Roboter sich bei Ansprache in Richtung des Sprechers dreht. Funktioniert noch nicht ganz sauber, wird aber. Zum Schluss verfügt das Mic Array über 8 LEDs, mit denen sich ein Alexa-ähnliches visuelles Feedback während des Gesprächs (oder auch in anderen Situationen) erzeugen lässt. Zugunsten dieser Lösung haben wir auf eine außerhalb des Mülleimers montierte LED, LCD oder sonstige Display-Vorrichtung verzichtet.
- Weiterhin angeschlossen sind ein einfacher USB Speaker zur Audio Ausgabe sowie die Raspi Kamera. Die Kamera ist die aktuell einzige Komponente, die außerhalb des Mülleimers montiert ist, das flache Kabel wird durch eine gefeilte Aussparung im Papierkorb geführt und durch eine Deko-Fliege abgedeckt. ;-)

Software-seitig kommen neben der eigenen Python-Programmierung insbesondere espeak-ng zur Sprachausgabe ohne Cloud Anbindung sowie die Porcupine und Rhino Wake-Word und Speech2Intent Engines (ebenfalls ohne Cloud Anbindung rein lokal) zum Einsatz. Einzige Cloud-Anwendung aktuell ist die Gesichtserkennung (To Do für die nächsten Tage: Objekterkennung).

Die Fähigkeiten des Roboters aktuell sind:

- Wie bisher Bewegungen in vier Richtungen, gesteuert über Spracheingabe ("Hey Kurt, fahre vorwärts!" , "Hey Kurt, drehe Dich um Kreis!" -> "Okay, drehe mich im Kreis!")
- Allgemein kurze Unterhaltungen ("Hey Kurt, wer bist Du?" -> "Ich bin Kurt, ohne Helm und ohne Gurt!")
- Gesichtserkennung bei Ansprache oder bei Frage "Wen siehst Du?" ("Hey, Kurt!" -> "Hallo, Patrick!")
- Hinderniserkennung vorwärts (stoppt bei 20 cm, mittels Ultraschallsensor)
- Selbstständigws Verändern der Betriebsmodi (d.h. bei Inaktivität geht der Roboter in einen "Sleep" Modus über, wo die Spracherkennung etc. nicht weiterlaufen und nur einige Sensoren aktiv bleiben)
- Web Oberfläche zum monitoren. Noch nicht ganz fertig, zeigt aktuell die ausgegebenen Log Infos (die sonst in der Shell angezeigt werden) im Web Browser an und wird künftig zusätzlich Batteriesstand/Temperatur (über API vom PiJuice verfügbar), letztes mit der Kamera aufgenommenes Bild (oder Video Stream) sowie die Navigationskarte (bei autonomem Navigieren, ganz große Baustelle noch) anzeigen und einen "Notaus" Button (falls man den physikalischen Button nicht erreichen kann und Kurt sich irgendwo verzettelt) enthalten. Web Oberfläche natürlich nur im heimischen LAN nutzbar.

Wer bis hierher gelesen hat, wird mit einigen bunten Bildern belohnt:

Anhang 35833
Anhang 35832
Anhang 35831

- - - Aktualisiert - - -

In Summe bin ich superzufrieden mit dem bisherigen Fortschritt. Ich hätte mit deutlich mehr und nachhaltigeren Problemchen gerechnet.

Nächste Schritte:

Neben der autonomen Navigation (ich plane, die Hall Effect Sensoren der Motoren an die Digital Ports des Grove Base HATS anzuschließen und somit die RPM der einzelnen Motoren zu erhalten, um einen besseren Geradeauslauf zu realisieren sowie auch um die zurückgelegte Distanz näherungsweise zu ermitteln), habe ich aktuell eher für mich schwierige Knackpunkte hinsichtlich der Energieversorgung.

Die Batterie für den PiJuice wird grundsätzlich mit einem JST-Stecker geliefert (dreipolig). Man muss den abtrennen und die einzelnen Drähte an das Batterieterminal schrauben. Da ich die Batterie künftig auf dem Mülleimer (also der umgekehrten Unterseite) und unterhalb des Huts befestigen möchte, muss ich die Verbindung verlängern. Hier hat mein erster Versuch (mit eigenen Lüsterklemmen) nicht funktioniert, da scheint nicht genug Strom anzukommen. Bin nicht sicher, woran das liegt.. ggf zu dünne Drähte. Gibt es hier Empfehlungen, welche Drähte/Kabel zu verwenden sind? Spielt hier die Länge der Kabel (also im Bereich von ca 15 cm im Original bis zu vielleicht 30-40 cm in der verlängerten Variante) eine signifikante Rolle? Eher nicht, oder?

Mein aktuell größtes Problem: Ziel ist es, dass Kurt sich selbstständig laden kann. Für die Raspi Stromversorgung über den PiJuice werde ich dazu ein induktives (wireless) Lademodul unten anbringen und eine passende Ladestation bauen (bzw. 3D-drucken lassen). Das induktive Lademodul (beide Parts) habe ich bereits. Es lädt mit 5V, 1.3. A max. Für den PiJuice sollte das in Ordnung gehen, der wird auch in vielen Szenarien über Solarzellen gespeist, das sehe ich mal als vergleichbar an (von der Stabilität des Ladestroms her).

Wie aber gehe ich mit der Stromversorgung für die drei Motoren um? Ständig 6 AAA Batterien auszutauschen ist erstens nicht autonom und auch nicht besonders nachhaltig. Im Idealfall würde Kurt an der Ladestation auch neuen Strom für die Motoren bekommen. Ich spiele hier mit dem Gedanken, einen 11.1V Lipo (also dreizellig á 3.7V) zu verwenden. Die Motoren sind in einer Spezifikation mit 9V und in einer anderen Spezifikation mit 9-12V beschrieben, daher würde ich mal optimistisch denken, dass sie mit einem 11.1V Lipo gut (oder sogar besser als aktuell?) betreibbar sind. Aber wie bekomme ich das Ladeszenario umgesetzt? Das Laden des 11.1V Lipos alleine fordert m. E. mindestens schon einen Balancer (so dass die drei Zellen gleichmäßig geladen werden) und entsprechende Overcharge-Protektion (oder gibt es vernünftige Lipos, die das bereits eingebaut haben?). Habe ich irgendeine Chance, den Eingangsstrom des induktiven Lademoduls erstens zu splitten und einen Teil zum PiJuice zu senden und einen Teil dann noch per Voltage Regulator von 5 V auf z.B. 12 Volt zum Laden des 11.1V Lipos anzuheben? Oder ist das völlig illusorisch? Hier kommt wieder meine relative Elektronik-Ahnungslosigkeit ins Spiel, aber ich möchte auch ungern riskante Experimente mit Lipos eingehen und einen Brand im Haus riskieren. Alternativ zum Splitten wäre ggf. noch eine zeitliche Unterscheidung denkbar, dass der Roboter selbstständig zunächst den Akku für den Raspi lädt und dann, per Relais o. Ä., den Charger für den Motor-Lipo aktiviert. Fragezeichen.

Da die Anwendung eher einer USV, denn einem Batteriebetrieb gleicht (letztlich steht auch ein Staubsaugerroboter 95% der Zeit nur in der Ladestation), würde ich mich in dieser Richtung mal umschauen (Suchbegriff Mini-USV). Letztlich müssten diese Geräte alle notwendigen Zusatzbeschaltungen (Schutz/Balancer/Ladeschaltung) bereits enthalten.

Naja - der PiJuice ist ja ein USV. Damit ist aber die Stromversorgung der Motoren noch nicht gelöst. Ich habe zu der spezifischen Frage einen Thread im Forum "Elektronik" aufgemacht:

https://www.roboternetz.de/community...it-und-Motoren

Es gibt mittlerweile einige Mini-USVs mit mehreren Ausgängen für unterschiedliche Spannungen (5,9,12V).
Ich kann da jetzt zwar keine direkt empfehlen, aber es scheint ein wachsender Markt zu sein.
Such mal nach "Mini USV 12V".

hallo allerseits,

ich beschäftige mich seit einiger zeit mit diesem thema.
Anhang 35844 Anhang 35845
Da bleibt das thema akku nicht aussen vor, ich denke es wird - auch was die sicherheit betrifft - überbewertet. Das hängt irgendwie auch mit dem zeitgeist zusammen - ja kein risiko eingehen, wenn jemand fragt, besser abraten, oder sein lassen sich mit solchen dingen auch nur zu beschäftigen...
in meinem roboter habe ich diesen akku eingebaut, funktioniert problemlos, mein haus steht immer noch...

der akku kann - so lange der roboter auf dem schreibtisch steht über eine normale ladebuchse geladen werden, die ladeelektronik ist mit drin, oder induktiv, oder per solarpanel., alles dazu- schaltbar, oder abschaltbar... Aus diesem akku werden alle erforderlichen arbeitsspannungen per stepdown erzeugt - 12V direkt an die motoren, 5V und 3.3V wo es auch immer gebraucht wird...

bei der auslegung des roboters bin ich am anfang auch vom raspi (zero) ausgegangen, bin aber inzwischen davon weg. Eignet sich m.e. nach überhaupt nicht z.b. zur motorsteuerung. Natürlich funktioniert eine motorsteuerung damit, ist aber ein sinnloser overshoot, jeder ESP ist da besser geeignet. Selbst das hochfahren des zero dauert viel zu lange...
Anhang 35843
jedes kästchchen auf dem bild entspricht einem modul, jedes modul hat einen wifi-fähigen microcontroler, meistens einen ESP8266, nur dort wo motoren gesteuert werden ist auch ein nano. Beim einschalten des roboters geht zunächst das ortungsmodul an, von dem aus können weitere module dazu oder auch wieder abgeschaltet werden. jetzt zunächstmal vom smartphone aus, später auch von einem zero aus, der die befehlsgewalt - neben der fernbedienung - haben soll. Aber keine sensoren, cameras, oder motoren direkt, dazu hat er seine "sklaven"...

Zitat:

---

Zitat von inka

...Da bleibt das thema akku nicht aussen vor, ich denke es wird - auch was die sicherheit betrifft - überbewertet. ...

---

Wenn Du mal vor der Ruine eines Hauses gestanden hast, in dem durch einen Explodierten LiPo-Akku ein Kellerbrand entstanden und durch den giftigen Rauch das ganze Haus ein wirtschaftlicher Totalschaden geworden ist, dann denkst Du anders. Oder die Garage des Flugmodellbau-Kollegen, die bis auf das Mauerwerk demontiert werden musst, inkl. unter Vollschutz den Putz von den Wänden hauen, weil auch dort erst ein Feuer entstanden ist und dann der giftige Rauch sich überall hingesetzt hat, ist ein schönes Beispiel dafür, warum man ALLERHÖCHSTE Sorgfalt bei der Pflege, Lagerung und Verwendung von Akkus walten lassen sollte.

Das waren nur die Beispiele, die ich persönlich kenne. Les' mal auf RC-Network nach, wie viele Leute da von explodierten Akkus schreiben. Da wundert es nicht, wenn die Leute die Akkus nur noch in einem alten Kühlschrank auf der Terasse lagern.


VG, Jürgen

ich muss zugeben, dass das was ich zu *meinem* umgang mit akkus geschrieben habe nur eine/meine meinung ist, kein wissen...

Das man LiPo-accus mit einem gewissen respekt zu behandeln hat sollte aber nicht ins extrem führen. Und LiPo und RC ist eine von extremen beanspruchungen, der da die akkus ausgesetzt sind. Und von dieser art akkuanwendung ist man im normalfall welten entfernt...

Nicht nur eine meinung...

Das mit Wartung und Pflege stimmt schon, wobei der vollautonome Einsatz eigentlich das Optimum darstellt, weil die Überwachung und Bewertung von Spannung, Strom, Temperatur und auch mechanischem Stress hier 24/7 erfolgt.
Mehr kann man eigentlich nicht tun. Wenn das nicht reicht, muss man eben ohne Lithium auskommen.

Hallo Inka,
leider hat die Beanspruchung der Akkus nicht wirklich was mit der Gefahr der LiPos zu tun. Es gibt ein paar Untersuchungen, die davon berichten, dass die Explosion der LiPos, sofern nicht durch mechanische Einflüsse verursacht, auf Verunreinigungen des Elektrolyt zurückzuführen sind. Leider hatte ich mir die Links zu den Untersuchungen nicht gespeichert, ansonsten würde ich die Untersuchungen hier verlinken.

Inka, leider bist Du nicht der Einzige, der so denkt. Ich lese gerade ein Buch https://www.amazon.de/gp/product/380...?ie=UTF8&psc=1 von Professor Gleißner über Risikomanagement. Dieser benennt mehrfach die Blindheit der Menschen bezüglich abstrakter Gefahren.
Vor 5 Jahren hätte niemand die realistische und wahrscheinliche, aber dennoch abstrakte Gefahr einer Pandemie, welche die Welt quasi lahmlegt, in Deutschland für möglich gehalten. Genauso ist ein Krieg in Europa statistisch überfällig gewesen, aber von allen wurde die Gefahr als "viel zu unwahrscheinlich" und "Unsinn" abgetan. Seit Februar haben sich zwei sehr abstrakte Risiken, die alle verdrängt haben, realisiert. Auf einmal werden Prepper nicht belächelt, sondern bewundert und Risikomanager haben urplötzlich Gehör bei Vorständen der Unternehmen.

VG, Jürgen

hi Jürgen,
mich als blind zu bezeichen ist reichlich übetrieben, auch wenn ich eine brille trage :-) sicher gehöre ich nicht zu den preppern, habe trotzdem bestimmte vorräte im haus und neuerdings auch ein batteriebetriebenes radio....

was die "über"-beanspruchung von akkus betrifft ist sie nun einmal unterscheidlich ob ich diese in einem gemütlich vor sich hinfahrendem roboter verwende oder in einem RC-auto, wo die volle leistung !jetzt! angefordert wird. Und das gleiche ist beim laden - RC-freaks kann es nicht schnell genug gehen, auch ein zeichen der heutigen zeit...

bei allem sollte man die kirche im dorf lassen...

Hallo Inka,

ich wollte dir nicht zu nahe treten!
Wie gesagt, die elektrische Belastung der Akkus hat nichts mit der Brandgefahr zu tun. Ansonsten müssten die Akkus der Pylonenflieger, die mit fast 300 KM/h durch die Gegend düsen, schon im Flug abbrennen. Interessanterweise brennen die meisten Akkus ab, wenn sie einfach nur rumliegen. Wenn Du schreibst, dass man die Kirche im Dorf lassen soll - ja, da bin ich bei dir! Es muss jeder selbst entscheiden, welche Risiken er Vermeiden, Bekämpfen/Heilen oder Auslagern will.
Ich habe meine Akkus auch nicht auf die Terrasse ausgelagert, aber sie liegen in zwei Munitionskisten, welche mit Rigipsplatten in Fächer unterteilt sind, in meinem Hobbykeller. Auf den Munitionskisten liegt ein 50l-Sack Löschkugeln, die jeden Brand hoffentlich sofort in CO2 ersticken.

VG, Jürgen

Hmm, ich dachte immer, die Feuerwehr taucht Akkubrände in Wasser, um die Wiederentzündung zu verhindern.

ob jetzt wasser oder löschkugeln ist eigentlich egal... Man müsste das ganze doch ein bischen im verhältnis sehen. Wieviel LiPo akkus sind geschätzt weltweit unterwegs? 10 milliarden? 100milliarden? Und wieviel davon sind explodiert, bzw. haben sich entzündet? 10? 100? 1000? natürlich ist es besonders schlimm wenn sowas einem selber passiert, aber munitionskisten? Fährst du eigentlich noch auto? Keine angst bei den millionen von rückrufaktionen? mann ey... es gibt keine perfekte 100%tige technik, aber das weisst doch jedes kind....

nur als info: ich habe ein sensor entwickelt der mir nachts signalisiert wenn ich auf dem rücken liege. Soll ich nicht, wegen schlafapnoe. Das ding muss ich mir mit einem gurt um die brust schnallen, sonst funktionioert es nicht. Und womit wird das ding betrieben? Dreimal darfst du raten :-)

Jeder arbeitet gegen die Risiken, die er für relevant hält. Ich kenne persönlich, nicht aus der Presse, rund ein halbes Dutzend Fälle, wo Lipos sich selbst entzündet haben. Zwei Fälle waren extrem, wie oben beschrieben. Sehr viele Modellbauer transportieren LiPos in sogenannten LiPo-Bags. Rate mal warum....
Wenn sich ein 100mA/h LiPo entzündet, hält sich der Schaden in Grenzen. Bei einem 5A/h-Akku ist das eine ganz andere Hausnummer. Wer noch nie einen LiPo hat abbrennen sehen: https://www.youtube.com/results?sear...lipo+explosion

Noch einen schönen Sonntag,
Jürgen

P.S.: Ja ich fahre Auto. Mein Auto hat viele Airbags, ABS, Abstandsradar, Spurhalteassistent, Müdigkeitswarner, etc. Wieso soll ich LiPos einfach so rumliegen lassen und auf mein Glück hoffen?

Zitat:

---

Zitat von jmoors

Wenn sich ein 100mA/h LiPo entzündet, hält sich der Schaden in Grenzen. Bei einem 5A/h-Akku ist das eine ganz andere Hausnummer.

---

ja, das sind wirklich unterschiedliche welten. Wie ich schon erwähnt habe. Und auch, dass man einen lipoakku mit gewissem respekt behandeln sollte. Ich weiss nicht ob sich in der comunity, die sich mit haushaltselektronik und kleinen robotern beschäftigt jemand findet, der einen lipoakku mit einem nagel und hammer traktiert. Da fehlt halt der respekt...

auch dir einen schönen restsonntag...