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
gruß inka
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:
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
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.
Geändert von Moppi (18.01.2022 um 13:13 Uhr)
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.
Diese Frage sollte hinreichend beantwortet sein, mitsamt Hintergrundinformationen warum und wie das funktionieren kann. Nochmal zur Erinnerung:Zitat von rhino25782
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:
- - - 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.
hi Jürgen,
mich als blind zu bezeichen ist reichlich übetrieben, auch wenn ich eine brille tragesicher 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...
gruß inka
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...
gruß inka
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.
Berechtigungen
Zitieren
Lesezeichen