Aufstrebende Idee

[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.

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)

[Donevan]

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.

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

[Peter(TOO)]

Hallo Don,

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.

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.

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)