Aufstrebende Idee

Morgen zusammen :)

Mein Traumprojekt ist ein Fahrzeug, das sich eigenständig bewegen kann. An meinem ersten Projekt habe ich wegen Platzmangel im Gehäuse und Konstruktionsfehlern an der Elektronik die Lust verloren, also fange ich nochmal von vorne an. Nachdem ich von alldem keine Ahnung habe, wird es wohl etwas länger dauern, aber gut Ding will weile haben heißt es doch. Dieser Herausforderung möchte ich mich gerne stellen.

Die Idee ist simpel: Ein Bodenfahrzeug, das sich je nach Vorgabe völlig eigenständig (autonom) durch das Gelände bewegen kann, das aber auch per Fernsteuerung oder vorgegebener Strecke fahren kann. Irgendwann, was ja das Nonplusultra wäre, wäre es schön wenn es auch alleine den Weg zu vorgegebenen GPS-Koordinaten finden würde. Die größten Schwierigkeiten werden die Konstruktion der Schaltkreise und ggf. eigener Platinen, die Vernetzung und insbesondere die Programmierung sein. Aber auch das Tetris mit den Bauteilen im Gehäuse wird sicher interessant. Kurzum wird also alles recht holprig.

Hauptaugenmerk soll dabei bei der Selbsterhaltung liegen. So soll der Robi z.B. merken, wenn es irgendwo plötzlich tief runter geht (z.B. Treppe) oder er in Begriff ist, in einen Tümpel zu fahren. Oder aber er soll erkennen, wenn die Akkuleistung für die vorgegebene Strecke nicht mehr ausreicht und stattdessen nach Hause zurückkehren. Außerdem sollte er sich möglichst vor der Überhitzung abschalten können und auch so konstruiert sein, dass er sich nicht durch Schaltungen und Fehlerströme selbst brutzelt. Auch sollte vermieden werden, dass er einfach "verschwindet", also unkontrolliert durch die Gegend bis ins Nirvana saust, oder aufgrund unzureichender Programmierung irgendwo an unbekannter Stelle stecken bleibt. Er sollte sich selbst so weit überwachen können, dass er Fehler erkennt, wie z.B. Bewegungsunfähigkeit durch Steckenbleiben oder Überrollen, oder durch Hardware-Defekt oder widersprüchliche Sensor-Daten.

Er soll Umgebungs- und Betriebsdaten vollständig erfassen und protokollieren können. Das können Dinge wie Wegstrecke, Stromverbrauch, Schaltvorgänge, oder aufgetretene Fehler sein. Doch all das zu seiner Zeit. Für den Anfang möchte ich einen Schaltkreis entwerfen, anhand dessen er sich selbst bewegen kann nach festen Vorgaben (z.B. fahre 30sec, fahre 10m weit). Danach soll er allmählich die Eigenständigkeit erlernen und dann die Fernsteuerung.

Wichtig ist auch die Geländegängigkeit. Demnach muss es also ein bewegliches Allradfahrwerk werden. Hierbei bin ich mir nicht sicher, ob es ein spezielles Roboter-Fahrwerk oder ein RC-Fahrzeug werden soll. Allrad-RCs treiben die Vorderachse nämlich idR über eine Welle an. Das bedeutet mechanische Teile, diese müssen regelmäßig gereinigt und gefettet werden und verschleißen überdies mit der Lebensdauer, was mir wenig zusagt. Ein Eigenbau steht allerdings vorerst auch außer Frage. Eine entsprechende Größe sollte er auch haben (mein Erster war VIEL zu klein), damit Akkus und Platinen auch bequem Platz finden. Das Gewicht ist mir dabei fürs erste relativ egal, auch wenn es eigentlich ein bedeutsamer Faktor wäre. Wichtig ist aber ein möglichst tief gelegener Schwerpunkt, damit er bei starken Steigungen nicht umkippen kann. Auch dies sollte er rechtzeitig erkennen und möglichst darauf reagieren. Geländegängig heißt dabei auch, dass er nicht unnötig verschmutzen oder gar von innen nass werden kann.

Fragen, die ich im Verlauf noch klären muss:

• Welches Gehäuse ist am besten?
• Welche Sensoren und Platinen werden benötigt?
• Wie viele Akkus werden benötigt bzw. auf welche Spannung muss das System ausgelegt werden (abhängig vom Gehäuse)?
• Wie baut man stabile, sichere Schaltkreise?
• Wie berechnet man wichtige Kenndaten (z.B. Kapazität, Stromstärke, Akkulaufzeit, etc.)?
• Wie erstellt man funktionierende Schaltkreise aus Zusammenspielen zwischen logischen ICs, Controllern, Registern, etc.?
• Wie dichte ich das Gehäuse ab, ohne dabei Stauwärme bis zur Überhitzung im Inneren zu provozieren?
• Programmierung
• Reicht eine reine Arduino-Steuerung aus, oder soll Arduino (vor allem für später interessant) Befehle vom Raspberry Pi entgegennehmen und stur verarbeiten? Sind ggf. mehrere Arduinos notwendig?
• Im Falle mehrerer Boards, wie werden diese am intelligentesten vernetzt? Ist ggf. ein Bus-System notwendig?
• Welche Mikrochips müssen verbaut werden und wie sind diese zu dimensionieren?

Notwendige Hardware, die im Verlauf konstruiert und gebaut werden muss:

• Motor-Treiber / H-Brücke
• Lade-Controller für Akkus
• Ggf. passives, wenn notwendig aktives Kühlsystem
• Strommesseinrichtung
• Intelligentes Spannungsmodul zum Abschalten nicht benötigter / defekter Hardware
• Beleuchtungseinrichtung
• Ggf. Netzwerkmodul

Ich bin sehr gespannt, was letztendlich dabei rauskommt. Ich bin zwar blutiger Anfänger, habe nur wenig Kleingeld für Kleinteile, komme auch nicht allzu oft dazu, aber dafür macht es mir irre Spaß, mich mit Elektronik zu befassen. Ich werde richtig zum Kind, wenn man dem Arduino sagt was er zu tun hat und er das dann völlig automatisch machen kann. Als planloses Spielkind wird das sicher nicht einfach. Mit Elektro kenne ich mich zwar aus, aber Schaltkreise, Prozessoren und ICs, das übersteigt meine Kenntnisse.
Mit ein Grund, warum ich mich hier angemeldet habe. Da werden bestimmt noch dutzende dumme Fragen aufkommen :cool: Insgesamt bin ich aber guter Dinge! Wenn ich einmal drin bin, hole ich mir wahrscheinlich vorwiegend Vorschläge und Inspirationen ein. Vielleicht kann ich ja irgendwann sogar selber Tipps geben? Mal sehen. ;) Bisher ist alles nur eine Idee auf dem Papier, aber es wird, ganz langsam und allmählich. Diesmal werde ich sorgfältiger arbeiten als beim letzten Mal, damit Schritt für Schritt etwas Brauchbares daraus wird.

Grüße,
Don

Hallo,

seeehr anspruchsvolle Zielsetzung.
Da Du deinen Wissensstand als recht gering angibst, solltest Du die angegebenen einzelnen Anforderungen auch als einzelen Aufgabenstellungen angehen.
Für den Anfang wäre die Empfehlung einen Bausatz oder sogar einen fertigen kleinen Roboter zu kaufen und dort den schwierigsten Teil, die Programmlogik anzugehen.
Z.B. die Grenzen der Odometrie ausloten und wie und mit welchen Sensoren sich die Navigation verbessern lässt.
Der Nächste Punkt wäre eine Ladestation und das rechtzeitige zurückkehren. (Später dann auch gerne mal mit länngeren Abstiegen auf der wegfahrt, da für den Anstieg auf der Rückfahrt ja mehr Strom benötigt wird und sich der Bedarf ausrechnen lässt)
Aus dem Drehzahlregelungs Thread habe ich die Vermutung das die Inspiration die NASA Marsrover sind.
In dem Fall am Besten nicht nur den Ausfall eines Rades detektieren, sondern auch Masnahmen wie Auskuppeln oder Anheben überdenken. Die NASA hat ja schon Erfahrung sammeln müssen wie das ist wenn man das vergisst und ein blockiertes Rad mit vollem Bodenkontakt mitziehen muß.

Da Du schlußendlich offroad unterwegs sein willst, wirst Du auch bei den Sensoren andere Wege wie bei Indoor Robotern gehen müssen. Angefangen bei selbstreinigung der Sensorköpfe, über Gedanken darüber welche Verfahren die besten Daten liefern, bis hin zum Zusammenführen der Daten und dem Datenformat einer Umgebungskarte.

Hallo Don,

Die Zielsetzung entspricht so in etwa einem Ing.-Studium mit Praxiserfahrung ;-)
Da wirst du wohl so die nächsten 10 Jahre beschäftigt sein.

Aber der Weg ist ja das Ziel.

Die wichtigsten Dinge, welche du wissen musst sind:

1. Jede Konstruktion ist ein einziger Kompromiss. Wenn du einen Parameter optimiert hast, ist ein anderer schlechter geworden! Dies gilt nicht nur für dich, schon die Bauteile sind so beschaffen.
Daraus ergibt sich:
2. Es gibt keine Ideale Lösung für ein Problem, nur ein Optimum unter den Vorgegebenen Bedingungen.
Da bei jeder Entwicklung die Vorgaben etwas anders sind, gibt es auch eine riesige Menge an gültigen Lösungen.

Ich persönlich mag hierarchische Systeme, also mehrere µCs welche zusammenarbeiten. Andere warnen vor solchen Lösungen! Das Hauptproblem liegt meistens in der Kommunikation zwischen den Teilen.
Meine Konstruktionen sind meist in intelligente Blöcke aufgeteilt. Dadurch ergeben sich definierte Schnittstellen. Das muss dann auch in der Kommunikation eingehalten werden, z.B. gibt man bei einem Fahrtregler nicht die Drehzahl im Befehl an, sondern die Geschwindigkeit, z.B. in m/s. Wenn man z.B. ein anderes Getriebe einbaut oder Räder mit einem anderen Durchmesser, betrifft dies dann nur die Software in diesem Modul, der Rest bleibt gleich. Des weiteren kann man besser Testen und simulieren, man hat immer definierte Schnittstellen. Ein Nachteil ist halt der etwas grössere Platzbedarf.

MfG Peter(TOO)

Zitat:

---

Zitat von i_make_it

Hallo,
Aus dem Drehzahlregelungs Thread habe ich die Vermutung das die Inspiration die NASA Marsrover sind.
In dem Fall am Besten nicht nur den Ausfall eines Rades detektieren, sondern auch Masnahmen wie Auskuppeln oder Anheben überdenken. Die NASA hat ja schon Erfahrung sammeln müssen wie das ist wenn man das vergisst und ein blockiertes Rad mit vollem Bodenkontakt mitziehen muß.

Da Du schlußendlich offroad unterwegs sein willst, wirst Du auch bei den Sensoren andere Wege wie bei Indoor Robotern gehen müssen. Angefangen bei selbstreinigung der Sensorköpfe, über Gedanken darüber welche Verfahren die besten Daten liefern, bis hin zum Zusammenführen der Daten und dem Datenformat einer Umgebungskarte.

---

Ja, das mit dem Rover kommt hin. Die Mechanismen die du angesprochen hast, faszinieren mich doch ganz schön, aber die müssen wohl auch eher ans Ende der Todo-Liste. Denn das wird erst richtig kompliziert, so einen Mechanismus zu konstruieren. Bei der NASA anrufen und nach Plänen fragen wird denke ich nicht gehen. :) Er soll auch durchs Gelände kraxeln, ja. An sowas wie Selbstreinigung habe ich dabei gar nicht gedacht, am Anfang. Werde ich aber auch mit aufnehmen. Wobei dann auch wieder ein wasserdichtes Gehäuse interessant wird wenn er sich eh schon so einsauen wird.

Zitat:

---

Zitat von Peter(TOO)

Hallo Don,
Die Zielsetzung entspricht so in etwa einem Ing.-Studium mit Praxiserfahrung ;-)
Da wirst du wohl so die nächsten 10 Jahre beschäftigt sein.

---

Zehn Jahre klingt super! Ich hatte nicht vor, den schon morgen fahrtüchtig zu haben. Nein, mich fasziniert der Erfolg an bewältigten Problemstellungen. Und wenn das heißt, dass er jahrelang aufgebockt auf der Werkbank steht, ist das okay. :) Da gehen meine Sorgen eher in Richtung des Billigplunders den man heutzutage bekommt, dass er anfängt zu rosten oder die ICs sich verabschieden.

Einzelne Module wie du sie erklärt hast bevorzuge auch ich. Allein schon aus dem Grund dass ich selber nicht mehr durchblicke wenn alles auf einem Haufen ist. Bloß von digitaler Vernetzung im Sinne von Datenprotokollen wie man sie von HTTP oder CAN kennt, bin ich noch sehr weit entfernt. Anfangs wird also ein binäres System (High / Low an Pin X) ausreichen müssen. Nachdem ich nie studiert habe, bin ich ja quasi Laie. Aber sonst wäre es wohl auch halb so spannend. :)

Grüße,
Don

Hallo Don,

Zitat:

---

Zitat von Donevan

Da gehen meine Sorgen eher in Richtung des Billigplunders den man heutzutage bekommt, dass er anfängt zu rosten oder die ICs sich verabschieden.

---

Die ICs sind da kein Problem mehr. Das war mal ein grosses Problem bei den ersten 64KiBit-RAMs. Die waren nach ein paar Wochen im Regal defekt!
Das Problem waren die, damals neuen, kleinere Strukturgrösse und das Problem, dass die Aluminium-Leiterbahnen, durch den unterschiedlichen Wärmeausdehnungekoeffezienten zu Silizium, mechanisch vorgespannt waren. Beim Lagern sind dann die Bahnen gerissen.
Kritisch dürften höchstens Nass-Elkos über diesen Zeitraum sein.

Zitat:

---

Zitat von Donevan

Einzelne Module wie du sie erklärt hast bevorzuge auch ich. Allein schon aus dem Grund dass ich selber nicht mehr durchblicke wenn alles auf einem Haufen ist. Bloß von digitaler Vernetzung im Sinne von Datenprotokollen wie man sie von HTTP oder CAN kennt, bin ich noch sehr weit entfernt.

---

i2C dürfte aber was sein. Da bekommst du fertige Bibliotheken und viele µC haben das schon als Hardware auf dem Chip.

Zitat:

---

Zitat von Donevan

Anfangs wird also ein binäres System (High / Low an Pin X) ausreichen müssen. Nachdem ich nie studiert habe, bin ich ja quasi Laie. Aber sonst wäre es wohl auch halb so spannend. :)

---

Das meinte ich auch mit den 10 Jahren; Du musst ein Studium nachholen und die Praxis lernen.

Das denken in Modulen hat mehrere Vorteile:
- Du denkst auch Strukturiert. Die Ganze Aufgabe zerlegst du zuerst in lauter Blackboxen, welche bestimme Teil-Aufgaben erfüllen und vor allem eine definierte Schnittstelle zu ihrer Umwelt haben. Manches kann man dabei auch für's erste nur vorsehen.
- Eine solche Blackbox kann man dann auch für sich alleine bauen und testen. Da hat man dann auch schon mal Teilerfolge.
- Wenn man so ein Modul als Software baut, verhindert man auch zu viel Spaghetticode. Andere Module greifen nur über die definierten Schnittstellen auf das Modul zu.
- Im Prinzip entspricht die Denkweise der ObjektOrientierten Programmierung.

MfG Peter(TOO)