Ich möchte das Thema "Modularität" auch einmal aus anderer Sichtweise betrachten. Hardware-Modularität löst nicht immer alle Probleme, sie kann auch neue schaffen. Man könnte sich z.B. vorstellen dass es einen intelligenten (mit CPU) Lidar-Sensor zur Kollisionserkennung und Ortung gibt oder einen intelligenten Ortungssensor auf Basis eines GPS. Wenn man bei solchen Systemen die Arbeits-Daten (das sind dann in der Regel 2D-Daten, d.h. "Karten") visualisieren möchte (für Display, Web etc. - was heute gängige Praxis nicht zuletzt für eine Fehlersuche ist) müsste man schnelle Schnittstellen (MBit, GBit) ergänzen. Schickt man hingegen nur die Roh-Daten zur CPU, reichen wieder langsame Schnittstellen.
Ardumower Board Version 1.2
- Ersteller markus-lbon-facebook
- Erstellt am
Hallo und ein Herzliches DANKE an alle die sich an der Diskussion beteiligen, das wollte ich erreichen !
Was würde es für eine Sinn machen eine Secker zu haben, an dem alle möglichen Signale anliegen, wir Jürgen geschrieben hat ? Aus meiner Sicht gar keinen. Es würde den Nachbau dermassen verkomplizieren, das für Einsteiger die Schwelle immer höher gelegt wird, von der Störanfälligkeit ganz zu schweigen. Ich würde es für Sinnvoll halten, sich auf möglichst wenige Protokolle zu beschränken. Analag und Digtal I/O sind ein muss, ganz klar. I2C hat schwächen aber für einen Rasenmäher doch wohl ausreichend und vor allem bei den Sensoren recht verbreitet.
Warum soll ich, für einen Motortreiber alle möglichen Signale / Protkolle bereitstellen, wenn die 99% nicht benötigt werden, nur weil vielleicht irgendwann mal jemand einen Motortreiber XY verwenden möchte ?
Es gibt eine einen Referenzaufbau für den Mower. Die Teile sind über den Shop leicht zu beschaffen und diese Teile sollten in erster Linie unterstützt werden. z.B. der Motortreiber durch das Protektorboard ist der sehr robust geworden und macht was er soll. Wozu also noch andere Motoreiber unterstützen ?
Über die Reserve Pins hat trotzdem jeder die Möglichkeit, seine Hardware anzubinden.
Modulares System. Was wir jetzt haben, ist für mich keine modulares System, das einzig Modulare ist das ich die Sensoren, die verwenden möchte einfach anschließen kann oder auch nicht. Das ist aber auch für einen Mower OK.
Viele User haben, glaube ich, nicht den Technischen Backround und werden eher von einem Modularen System abgeschreckt, wenn sie nicht genau wissen was dann alles brauchen.
In einigen bereichen, da gebe ich Rajiva recht hätte es aber Vorteile, z.B. Odometrie Auswertung.
Deswegen, Sensoren nur dort in Module auslagern, wo es nötig ist.
Klar hat ein System, wie von Jürgen vorgeschlagen, seinen Reiz, was man damit alles machen könnte ist Fantastisch aber dann würde ich eher auf ein ROS System setzen. hier geht es um einen Rasenmäher und ich sehe dabei ganz klar die aus Kaufmännischer Sicht die Kosten.
Es Beispiel der Bumperdino. Tolle Hardware aber kostet 60,00 €. Das ist er bestimmt auch Wert. Das Problem ist aber das wenn ich alle möglichen Sensoren so auslagere, liegen wir schnell im vierstelligen Bereich, will man das und eine Kollisionserkennung kann ich auch mit eine paar Mikroschaltern aufbauen.
Bitte nicht falsch verstehen, ich finde die Idee klasse, halte sie aber für zu teuer, für das was sie macht.
Da schließe ich mich Olaf Jaster, im bezug auf Modulare System an, nicht übertreiben.
Grundlegend sollte man sich erstmal auf einen Prozessor einigen. Ich denke der Mega ist in dem meisten bereichen völlig überfordert, das liegt nicht nur an der Geschwindigkeit, schon alleine die Probleme mit den Interrupts. Deswegen sollten, aus meiner Sicht nur noch der Due unterstützt werden, optional der Otto, wenn er denn mal irgendwann kommt.
Der Mega taugt, aus meiner sicht nur für eine ganz einfache Variante, mit Perimeter und Bumper.
Messermodulation, Odometrie, IMU usw. überlasten ihn völlig.
Wenn dann nur noch ein Prozessor unterstützt wird, würde das auch die Softwarepflege vereinfachen.
Was würde es für eine Sinn machen eine Secker zu haben, an dem alle möglichen Signale anliegen, wir Jürgen geschrieben hat ? Aus meiner Sicht gar keinen. Es würde den Nachbau dermassen verkomplizieren, das für Einsteiger die Schwelle immer höher gelegt wird, von der Störanfälligkeit ganz zu schweigen. Ich würde es für Sinnvoll halten, sich auf möglichst wenige Protokolle zu beschränken. Analag und Digtal I/O sind ein muss, ganz klar. I2C hat schwächen aber für einen Rasenmäher doch wohl ausreichend und vor allem bei den Sensoren recht verbreitet.
Warum soll ich, für einen Motortreiber alle möglichen Signale / Protkolle bereitstellen, wenn die 99% nicht benötigt werden, nur weil vielleicht irgendwann mal jemand einen Motortreiber XY verwenden möchte ?
Es gibt eine einen Referenzaufbau für den Mower. Die Teile sind über den Shop leicht zu beschaffen und diese Teile sollten in erster Linie unterstützt werden. z.B. der Motortreiber durch das Protektorboard ist der sehr robust geworden und macht was er soll. Wozu also noch andere Motoreiber unterstützen ?
Über die Reserve Pins hat trotzdem jeder die Möglichkeit, seine Hardware anzubinden.
Modulares System. Was wir jetzt haben, ist für mich keine modulares System, das einzig Modulare ist das ich die Sensoren, die verwenden möchte einfach anschließen kann oder auch nicht. Das ist aber auch für einen Mower OK.
Viele User haben, glaube ich, nicht den Technischen Backround und werden eher von einem Modularen System abgeschreckt, wenn sie nicht genau wissen was dann alles brauchen.
In einigen bereichen, da gebe ich Rajiva recht hätte es aber Vorteile, z.B. Odometrie Auswertung.
Deswegen, Sensoren nur dort in Module auslagern, wo es nötig ist.
Klar hat ein System, wie von Jürgen vorgeschlagen, seinen Reiz, was man damit alles machen könnte ist Fantastisch aber dann würde ich eher auf ein ROS System setzen. hier geht es um einen Rasenmäher und ich sehe dabei ganz klar die aus Kaufmännischer Sicht die Kosten.
Es Beispiel der Bumperdino. Tolle Hardware aber kostet 60,00 €. Das ist er bestimmt auch Wert. Das Problem ist aber das wenn ich alle möglichen Sensoren so auslagere, liegen wir schnell im vierstelligen Bereich, will man das und eine Kollisionserkennung kann ich auch mit eine paar Mikroschaltern aufbauen.
Bitte nicht falsch verstehen, ich finde die Idee klasse, halte sie aber für zu teuer, für das was sie macht.
Da schließe ich mich Olaf Jaster, im bezug auf Modulare System an, nicht übertreiben.
Grundlegend sollte man sich erstmal auf einen Prozessor einigen. Ich denke der Mega ist in dem meisten bereichen völlig überfordert, das liegt nicht nur an der Geschwindigkeit, schon alleine die Probleme mit den Interrupts. Deswegen sollten, aus meiner Sicht nur noch der Due unterstützt werden, optional der Otto, wenn er denn mal irgendwann kommt.
Der Mega taugt, aus meiner sicht nur für eine ganz einfache Variante, mit Perimeter und Bumper.
Messermodulation, Odometrie, IMU usw. überlasten ihn völlig.
Wenn dann nur noch ein Prozessor unterstützt wird, würde das auch die Softwarepflege vereinfachen.
Hi UweZ
Your first link and this one work well
but i can't open the kicad PCB view
Error each time,maybe some file are missing.
Kicad work perfectly with V1.2 off the board.
Here the Screen and error
Thanks for your help.
By
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/3545/kicaderr.jpg/
Your first link and this one work well
but i can't open the kicad PCB view Error each time,maybe some file are missing.
Kicad work perfectly with V1.2 off the board.
Here the Screen and error
Thanks for your help.
By
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/3545/kicaderr.jpg/
Zuletzt bearbeitet von einem Moderator:
kurzschuss
Administrator
Ich benutze eine neuere Version von KICad.
Die hat eine etwas andere neuere Lib und Footprint Verwaltung.
Installiere bitte diese Version.
http://downloads.kicad-pcb.org/windows/nightly/
Hier habe ich mal eine Anleitung dazu gemacht leider nur in Deutsch einfach mal mit Google Translate übersetzen.
wenn es dann immer noch nicht geht einmal melden. http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
In der 3D Ansicht kommt es zu einer Fehlermeldung. Das ist Normal. einfach ignorieren. Es handelt sich um die 3D Ansicht des Mega. Dort habe ich den Pfad in der 3D Ansicht extra falsch geschrieben um voll auf die Platine sehen zu können.
Der Dateiname für die 3D Ansicht für den Mega ist ${KISYS3DMOD}/Zimprich.3dshapes/ArduinoMegaShield.wrll
Das muss geändert werden in ${KISYS3DMOD}/Zimprich.3dshapes/ArduinoMegaShield.wrl
http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
_______________________________________________________
I use a newer version of KICad.
The has a slightly different newer Lib and Footprint administration.
Please install this version.
http://downloads.kicad-pcb.org/windows/nightly/
Here I have times a guidance made to it unfortunately only translated in German simply times with Google Translate.
If it still does not go once report. http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
In the 3D view, there is an error message. That is normal. simply ignore. It is the 3D view of the Mega. There I have the path in the 3D view extra misspelled to fully to see the circuit board.
The file name for the Mega view is $ {KISYS3DMOD} /Zimprich.3dshapes/ArduinoMegaShield.wrll
This needs to be changed in $ {KISYS3DMOD} /Zimprich.3dshapes/ArduinoMegaShield.wrl
http://www.ardumower.de/index.php/en/forum/ardumower-platinen/1082-kicad
Gruß Uwe
Die hat eine etwas andere neuere Lib und Footprint Verwaltung.
Installiere bitte diese Version.
http://downloads.kicad-pcb.org/windows/nightly/
Hier habe ich mal eine Anleitung dazu gemacht leider nur in Deutsch einfach mal mit Google Translate übersetzen.
wenn es dann immer noch nicht geht einmal melden. http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
In der 3D Ansicht kommt es zu einer Fehlermeldung. Das ist Normal. einfach ignorieren. Es handelt sich um die 3D Ansicht des Mega. Dort habe ich den Pfad in der 3D Ansicht extra falsch geschrieben um voll auf die Platine sehen zu können.
Der Dateiname für die 3D Ansicht für den Mega ist ${KISYS3DMOD}/Zimprich.3dshapes/ArduinoMegaShield.wrll
Das muss geändert werden in ${KISYS3DMOD}/Zimprich.3dshapes/ArduinoMegaShield.wrl
http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
_______________________________________________________
I use a newer version of KICad.
The has a slightly different newer Lib and Footprint administration.
Please install this version.
http://downloads.kicad-pcb.org/windows/nightly/
Here I have times a guidance made to it unfortunately only translated in German simply times with Google Translate.
If it still does not go once report. http://www.ardumower.de/index.php/de/forum/ardumower-platinen/1082-kicad
In the 3D view, there is an error message. That is normal. simply ignore. It is the 3D view of the Mega. There I have the path in the 3D view extra misspelled to fully to see the circuit board.
The file name for the Mega view is $ {KISYS3DMOD} /Zimprich.3dshapes/ArduinoMegaShield.wrll
This needs to be changed in $ {KISYS3DMOD} /Zimprich.3dshapes/ArduinoMegaShield.wrl
http://www.ardumower.de/index.php/en/forum/ardumower-platinen/1082-kicad
Gruß Uwe
elektronikjogi
Moderator
Hallo an alle,
vielen Dank für die ersten Beiträge.
Da eine Diskussion ohne Moderation recht wenig bringt, übernehme ich diese Funktion als Team-Mitglied.
Zuerst was in eigener Sache.:
Was ich über den Stecker für die Motortreiber geschrieben habe sollte nur ein Beispiel sein wie eine Diskussion aussehen sollte bei der es um eine Lösung geht und nicht um eine Diskussion bei der es nur ums Diskutieren geht (sogenannte Glaubensfragen. Die einen sagen es gibt Gott die anderen sagen es gibt ihn nicht.Wer hat recht? Das gehört in einen anderen Fachbereich jedoch nicht zu den Naturwissenschaften oder Technik. Der Glaube eines Menschen ist nicht beweißbar oder antastbar (Killerargument). Das blende ich in der Zusammenfassung immer mit einem Vermerk aus.)
Das zweite eine Diskussion um BumperDuino ja/nein steht nicht auf dem Programm. Das hat einen einfachen Grund: Die BumperDuino wurde von mir entwickelt um eine einfache Lösung für das Bumper-Thema ohne Mechanik zu zeigen. Deswegen steht diese im Shop auch unter der Rubrik Dein Projekt. Was bedeutet jeder kann hier wenn Markus das möchte seine Projekte der Allgemeinheit zugänglicher machen. Sie gehört nicht zum ArduMower-Projekt sie passt nur dazu und wird aus diesem Grund auch beschrieben (wie so viele andere Lösungen auch).
Irgendwann muss man sich entscheiden, hat aber dann zumindest alle Für und Wieder so gut es ging beleuchtet.
An diesem Punkt sind wir ja noch lange nicht.
Es gibt auch kein Naturgesetz das besagt, dass Ingenieure, Techniker, Hobbyisten etc. bei einer technischen Lösung glückliche Menschen sind. Es wird immer auf die ein oder andere Weise ein Kompromiss sein.
Zum Abschluss der Einleitung möchte ich gerne einen guten Freund und Kollegen zitieren der in einem Vortrag mal folgendes gesagt hat.:
Bei einem theoretischen Physiker funktioniert kein alltagstaugliches Gerät, aber er kann genau erklären warum. Ein Techniker bekommt alles zum Laufen weiß aber oft nicht wieso. Machen Sie einfach beides, bringen Sie alles zum laufen und wissen Sie auch warum...
In diesem Sinne fasse ich die Beiträge mal kurz zusammen. Sollte ich jemanden von den Teilnehmern missverstanden haben, bitte ich dies zu entschuldigen und dies dann als Anmerkung richtigzustellen. Ich werde es dann entsprechend in der Zusammenfassung ändern.
Alexander zusammengefasst:
Modularität hat den Nachteil das Hardware-Schnittstellen bei datenintensiven Sensoren für die Visualisierung sehr leistungsfähig seien müssen, was bei einer direkten Anbindung an CPU/MCU ohne einen Bus-System/Modulschnittstelle nicht erforderlich ist. http://www.ardumower.de/index.php/d...ardumower-board-version-1-2/reply/10949#10941
StefanM zusammengefasst:
Oberer Abschnitt: (Ich lasse den Stecker/Motortreiber hier weg.) Das Ardumower-Board und dessen Zubehör ist durch den Shop leicht und gut beschaffbar. Wozu andere Komponenten unterstützen. Wer Erweiterungen haben möchte kann dies gut mit den Reserve PINs auf dem ArduMowerMain machen. Ein Modularer Aufbau ist nicht notwendig.
Unterer Abschnitt: (Die Glaubensfrage lasse ich hier weg, da man über Glauben keine belegbaren Ergebnisse erzielt. Die Kaufmännische Sicht lasse ich weg da dies nicht Teil der Diskussion ist)) Bei manchen Sensoren ist ein Modulsystem sinnvoll zB. diejenigen die große CPU/MCU Last bedeuten. Ein Modulares-System ist dann richtig wenn es nicht übertrieben wird (siehe auch Olaf Jaster).
Die erste und wichtigste Frage ist, dass man sich auf ein CPU-Typ einigt und nur dieser wird unterstützt. Um die Softwarepflege und die Systempflege zu vereinfachen. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=60#10942
Boilevin zusammengefasst:
schließt sich in allem StefanM an. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=60#10944
Olaf Jaster zusammengefasst:
Ein Modulares-System ist gut solange man es nicht übertreibt. Lieber wenige dafür gut getestete Komponenten die lange unterstützt werden. Die wichtigste Frage ist die Ausfallsicherheit und Störungsanfälligkeit. Hierauf ist besonders Wert zu legen. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=40#10931
Rajiva zusammengefasst:
Es muss nicht alles von einer CPU/MCU bearbeitet werden. Besser ist es das ganze auf mehrere zu verteilen. Wobei die Aufteilung sinnvoll erfolgen muss in Stromversorgung, Sensorik, CPU/MCU (hier meinst du vermutlich auch Motortreiber?). Die Busanbindung ist über einen I2C genau das richtige. Die ArduMower-Main ist kein echtes Modulares-System. Die Komplexität der Software wird dadurch zwar größer, aber verbunden mit einer verbesserten Funktion nicht von Bedeutung. Software hat immer Fehler aber gerade mit Software kann man ein System besonders gestalten solange die Rechenleistung ausreichend ist. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=40#10924
Jürgen: (als Moderator darf ich nur Fragen stellen und nicht Bewerten.)
Ich möchte an dieser Stelle einen Diskussionszweig beenden.
Die ArduMower-Main ist kein Modulares-System sondern ein Modul-System. Sie kann jedoch Teil eines Modularen-Systems sein.
Begründung: 1. Die Ardumower-Main ist was sie ist. Dadurch spielt das für die jetzige Diskussion keine Rolle.
2. Durch die Anbindung z.B. per USB kann diese aus Sicht einer übergeordneten CPU(z.B. RPi), Teil eines Verteilten
Systems sein.
Wenn sich die Beteiligten auf diesen Konsens einigen ist dieser Diskussionszweig beendet. Ansonsten bitte Widerspruch einlegen. Hier entscheidet die einfache Mehrheit.
Aus den Antworten filtere ich folgende Fragestellungen.:
1. Müssen wir uns auf eine CPU/MCU festlegen?
2. Was für ein System ist sinnvoll? (Von was sprechen wir hier einem Verteiltem-System, Skalierbarem-System, Modularem-System oder einer Mischung)
3. Bei welchen System-Teilen ist es sinnvoll diese auszulagern?
Wenn möglich bitte die Antworten so lang wie nötig und so kurz wie möglich. Am besten noch mit einer Begründung. Das macht mir die Arbeit leichter.
Euer
Jürgen
vielen Dank für die ersten Beiträge.
Da eine Diskussion ohne Moderation recht wenig bringt, übernehme ich diese Funktion als Team-Mitglied.
Zuerst was in eigener Sache.:
Was ich über den Stecker für die Motortreiber geschrieben habe sollte nur ein Beispiel sein wie eine Diskussion aussehen sollte bei der es um eine Lösung geht und nicht um eine Diskussion bei der es nur ums Diskutieren geht (sogenannte Glaubensfragen. Die einen sagen es gibt Gott die anderen sagen es gibt ihn nicht.Wer hat recht? Das gehört in einen anderen Fachbereich jedoch nicht zu den Naturwissenschaften oder Technik. Der Glaube eines Menschen ist nicht beweißbar oder antastbar (Killerargument). Das blende ich in der Zusammenfassung immer mit einem Vermerk aus.)
Das zweite eine Diskussion um BumperDuino ja/nein steht nicht auf dem Programm. Das hat einen einfachen Grund: Die BumperDuino wurde von mir entwickelt um eine einfache Lösung für das Bumper-Thema ohne Mechanik zu zeigen. Deswegen steht diese im Shop auch unter der Rubrik Dein Projekt. Was bedeutet jeder kann hier wenn Markus das möchte seine Projekte der Allgemeinheit zugänglicher machen. Sie gehört nicht zum ArduMower-Projekt sie passt nur dazu und wird aus diesem Grund auch beschrieben (wie so viele andere Lösungen auch).
Irgendwann muss man sich entscheiden, hat aber dann zumindest alle Für und Wieder so gut es ging beleuchtet.
An diesem Punkt sind wir ja noch lange nicht.
Es gibt auch kein Naturgesetz das besagt, dass Ingenieure, Techniker, Hobbyisten etc. bei einer technischen Lösung glückliche Menschen sind. Es wird immer auf die ein oder andere Weise ein Kompromiss sein.
Zum Abschluss der Einleitung möchte ich gerne einen guten Freund und Kollegen zitieren der in einem Vortrag mal folgendes gesagt hat.:
Bei einem theoretischen Physiker funktioniert kein alltagstaugliches Gerät, aber er kann genau erklären warum. Ein Techniker bekommt alles zum Laufen weiß aber oft nicht wieso. Machen Sie einfach beides, bringen Sie alles zum laufen und wissen Sie auch warum...
In diesem Sinne fasse ich die Beiträge mal kurz zusammen. Sollte ich jemanden von den Teilnehmern missverstanden haben, bitte ich dies zu entschuldigen und dies dann als Anmerkung richtigzustellen. Ich werde es dann entsprechend in der Zusammenfassung ändern.
Alexander zusammengefasst:
Modularität hat den Nachteil das Hardware-Schnittstellen bei datenintensiven Sensoren für die Visualisierung sehr leistungsfähig seien müssen, was bei einer direkten Anbindung an CPU/MCU ohne einen Bus-System/Modulschnittstelle nicht erforderlich ist. http://www.ardumower.de/index.php/d...ardumower-board-version-1-2/reply/10949#10941
StefanM zusammengefasst:
Oberer Abschnitt: (Ich lasse den Stecker/Motortreiber hier weg.) Das Ardumower-Board und dessen Zubehör ist durch den Shop leicht und gut beschaffbar. Wozu andere Komponenten unterstützen. Wer Erweiterungen haben möchte kann dies gut mit den Reserve PINs auf dem ArduMowerMain machen. Ein Modularer Aufbau ist nicht notwendig.
Unterer Abschnitt: (Die Glaubensfrage lasse ich hier weg, da man über Glauben keine belegbaren Ergebnisse erzielt. Die Kaufmännische Sicht lasse ich weg da dies nicht Teil der Diskussion ist)) Bei manchen Sensoren ist ein Modulsystem sinnvoll zB. diejenigen die große CPU/MCU Last bedeuten. Ein Modulares-System ist dann richtig wenn es nicht übertrieben wird (siehe auch Olaf Jaster).
Die erste und wichtigste Frage ist, dass man sich auf ein CPU-Typ einigt und nur dieser wird unterstützt. Um die Softwarepflege und die Systempflege zu vereinfachen. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=60#10942
Boilevin zusammengefasst:
schließt sich in allem StefanM an. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=60#10944
Olaf Jaster zusammengefasst:
Ein Modulares-System ist gut solange man es nicht übertreibt. Lieber wenige dafür gut getestete Komponenten die lange unterstützt werden. Die wichtigste Frage ist die Ausfallsicherheit und Störungsanfälligkeit. Hierauf ist besonders Wert zu legen. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=40#10931
Rajiva zusammengefasst:
Es muss nicht alles von einer CPU/MCU bearbeitet werden. Besser ist es das ganze auf mehrere zu verteilen. Wobei die Aufteilung sinnvoll erfolgen muss in Stromversorgung, Sensorik, CPU/MCU (hier meinst du vermutlich auch Motortreiber?). Die Busanbindung ist über einen I2C genau das richtige. Die ArduMower-Main ist kein echtes Modulares-System. Die Komplexität der Software wird dadurch zwar größer, aber verbunden mit einer verbesserten Funktion nicht von Bedeutung. Software hat immer Fehler aber gerade mit Software kann man ein System besonders gestalten solange die Rechenleistung ausreichend ist. http://www.ardumower.de/index.php/d...05-ardumower-board-version-1-2?start=40#10924
Jürgen: (als Moderator darf ich nur Fragen stellen und nicht Bewerten.)
Ich möchte an dieser Stelle einen Diskussionszweig beenden.
Die ArduMower-Main ist kein Modulares-System sondern ein Modul-System. Sie kann jedoch Teil eines Modularen-Systems sein.
Begründung: 1. Die Ardumower-Main ist was sie ist. Dadurch spielt das für die jetzige Diskussion keine Rolle.
2. Durch die Anbindung z.B. per USB kann diese aus Sicht einer übergeordneten CPU(z.B. RPi), Teil eines Verteilten
Systems sein.
Wenn sich die Beteiligten auf diesen Konsens einigen ist dieser Diskussionszweig beendet. Ansonsten bitte Widerspruch einlegen. Hier entscheidet die einfache Mehrheit.
Aus den Antworten filtere ich folgende Fragestellungen.:
1. Müssen wir uns auf eine CPU/MCU festlegen?
2. Was für ein System ist sinnvoll? (Von was sprechen wir hier einem Verteiltem-System, Skalierbarem-System, Modularem-System oder einer Mischung)
3. Bei welchen System-Teilen ist es sinnvoll diese auszulagern?
Wenn möglich bitte die Antworten so lang wie nötig und so kurz wie möglich. Am besten noch mit einer Begründung. Das macht mir die Arbeit leichter.
Euer
Jürgen
Hi UweZ
Thanks you very much Kicad work and i can perfectly view the board in 3D but i wanted to view the complete schema of the board (V1.3) and i did not find the .PDF file like in the (V1.2) version.
If i open the file named "ardumower mega shield svn.sch" there is only the part for the battery charging
Maybee i forget Something ????
By
Thanks you very much Kicad work and i can perfectly view the board in 3D but i wanted to view the complete schema of the board (V1.3) and i did not find the .PDF file like in the (V1.2) version.
If i open the file named "ardumower mega shield svn.sch" there is only the part for the battery charging
Maybee i forget Something ????
By
Hallo Jürgen,
est mal danke das du die Moderation übernimmst, damit das nicht abdriftet.
ch wollte den Bumperdino nicht verwerfen. Das ist eine Tolle Lösung. Mir ging es, und da bin ich bei Punkt zwei, um die Kaufmännische Sicht. Er diente als Beispiel was ein System kosten kann, wenn es zu Aufwendig wird.
Was nutzt uns das tollste System, wenn es keiner kauft.
Deswegen sollte auch dieser Aspekt berücksichtigt werden. Damit meine ich nicht unbedingt das wir das Diskutieren sollen aber in unseren Überlegen berücksichtigen.
Ansonsten stimme ich dir zu. Allerdings bleibt noch eine Frage offen, um das mal in die Runde zu werfen. Was ist mit der geplanten 1.3 Version ? Das sollte dann aber separat Diskutiert werden und hier nicht zu viel durcheinander zu erhalten.
Deine Zusammenfassung trifft die Grundlegende Fragestellung weitestgehend sehr genau.
zu. 1
Auf ein System, vorläufig, festlegen hat den Vorteil das die Wartung einfacher ist. So wie es jetzt ist.
Wir haben ein System für den Mega, wer möchte kann es auf einen Due aufrüsten. Das ist aber mit Aufwand verbunden.
Wenn wir wir zukünftige beides Unterstützen, müssen Varianten berücksichtigt werden. Das geht schon mit den Interrupts los. Bei dem Unterschied was ein Due/Otto im Verhältnis zu einem Mega mehr kostet, dürfte sich der Aufwand nicht lohnen.
zu. 2
stehe ich nach wie vor dazu, Modular/Verteilt, dort wo es Sinnvoll und Notwendig ist.
Alles Modular hat seinen Reiz, keine Frage. Die Möglichkeiten sind verlockend aber da kommt dann wieder, bei mir der Kaufmann durch
zu. 3
Bei rechenintensiven Aufgaben, die den restlichen Aufwand stören. z.B. Odometrie, Messermodulation
Allerdings ist die frage ob das dann mt einem Due/Otto nötig ist oder ob dieser die Aufgabe bewältigen kann ohne den Restlichen ablauf zu stören.
Im Augenblicke haben wir das Problem, um bei meinem Beispiel zu bleiben, das drei Signale einen Interrupt auslösen.
Das betrifft aber eher die 1,3 Version.
Uwe könnte ja einen 1,3 Threat starten, in dem er den derzeitigen Stand nochmal zusammenfasst und wir dann dort darüber Diskutieren können, denn das ist das nächste Ziel. Hier reden wir über die Zukunft.
Stefan
est mal danke das du die Moderation übernimmst, damit das nicht abdriftet.
ch wollte den Bumperdino nicht verwerfen. Das ist eine Tolle Lösung. Mir ging es, und da bin ich bei Punkt zwei, um die Kaufmännische Sicht. Er diente als Beispiel was ein System kosten kann, wenn es zu Aufwendig wird.
Was nutzt uns das tollste System, wenn es keiner kauft.
Deswegen sollte auch dieser Aspekt berücksichtigt werden. Damit meine ich nicht unbedingt das wir das Diskutieren sollen aber in unseren Überlegen berücksichtigen.
Ansonsten stimme ich dir zu. Allerdings bleibt noch eine Frage offen, um das mal in die Runde zu werfen. Was ist mit der geplanten 1.3 Version ? Das sollte dann aber separat Diskutiert werden und hier nicht zu viel durcheinander zu erhalten.
Deine Zusammenfassung trifft die Grundlegende Fragestellung weitestgehend sehr genau.
zu. 1
Auf ein System, vorläufig, festlegen hat den Vorteil das die Wartung einfacher ist. So wie es jetzt ist.
Wir haben ein System für den Mega, wer möchte kann es auf einen Due aufrüsten. Das ist aber mit Aufwand verbunden.
Wenn wir wir zukünftige beides Unterstützen, müssen Varianten berücksichtigt werden. Das geht schon mit den Interrupts los. Bei dem Unterschied was ein Due/Otto im Verhältnis zu einem Mega mehr kostet, dürfte sich der Aufwand nicht lohnen.
zu. 2
stehe ich nach wie vor dazu, Modular/Verteilt, dort wo es Sinnvoll und Notwendig ist.
Alles Modular hat seinen Reiz, keine Frage. Die Möglichkeiten sind verlockend aber da kommt dann wieder, bei mir der Kaufmann durch
zu. 3
Bei rechenintensiven Aufgaben, die den restlichen Aufwand stören. z.B. Odometrie, Messermodulation
Allerdings ist die frage ob das dann mt einem Due/Otto nötig ist oder ob dieser die Aufgabe bewältigen kann ohne den Restlichen ablauf zu stören.
Im Augenblicke haben wir das Problem, um bei meinem Beispiel zu bleiben, das drei Signale einen Interrupt auslösen.
Das betrifft aber eher die 1,3 Version.
Uwe könnte ja einen 1,3 Threat starten, in dem er den derzeitigen Stand nochmal zusammenfasst und wir dann dort darüber Diskutieren können, denn das ist das nächste Ziel. Hier reden wir über die Zukunft.
Stefan
Hi Jürgen,
erst mal danke für die Zusammenfassung, versuche mal (diesmal kürzer) meinen Senf dazu abzugeben. Bin es im Hobbybereich nicht gewohnt so "streng" zu kommunizieren.
Derzeit sieht mein Konzept 5 Platinen vor. Spannungsversorgung + Ladegedöns (hier muss ich noch prüfen ob der Verpolungsschutz wirklich 2V Spannungsabfall erzeugt. Kann ich mir bei dem RDS on gar nicht richtig vorstellen.), Main Unit, die zwei Protektorboards für die Motoren und ein Sensorboard, für meine Sensoren und Bumper, und um u.a. auch Störungen auf langen Sensorleitungen zu vermeiden. Als Bus setze ich auf I2C da sich über diesen Bus auch alle MCUs flashen lassen.
für diese Platine vorgesehen ist wahrscheinlich nicht. Ich für meinen Teil würde nur ungern eine weitere große Platine, eine habe ich ja schon gekauft und werde sie nicht verwenden, mit all dem drum und dran entsorgen wollen nur weil ich später mal auf eine neuere CPU Generation umsteigen möchte und die Platine eben nicht mehr kompatibel ist.
Grüße
Rajiva
erst mal danke für die Zusammenfassung, versuche mal (diesmal kürzer) meinen Senf dazu abzugeben. Bin es im Hobbybereich nicht gewohnt so "streng" zu kommunizieren.
ich kann hier nur für mich sprechen aber würde Deine Frage mit einem klaren jein beantworten. In meinem geplanten Design, Platinen sind bereits gezeichnet und suchen eine günstige Produktion, habe ich mich beim Fahrwerk auch auf die Popolu Treiber festgelegt, beim Mähmotor werde ich aber einen anderen Weg gehen. Hier halte ich den Popolu, wie wohl StefanM auch, für völlig Overkill und, trotz das ich einige Treiber im Shop gekauft habe, für zu teuer. Der Mähmotor wird bei mir über eine externe Treiberstufe angebunden werden.Jürgen Lange schrieb:
Derzeit sieht mein Konzept 5 Platinen vor. Spannungsversorgung + Ladegedöns (hier muss ich noch prüfen ob der Verpolungsschutz wirklich 2V Spannungsabfall erzeugt. Kann ich mir bei dem RDS on gar nicht richtig vorstellen.), Main Unit, die zwei Protektorboards für die Motoren und ein Sensorboard, für meine Sensoren und Bumper, und um u.a. auch Störungen auf langen Sensorleitungen zu vermeiden. Als Bus setze ich auf I2C da sich über diesen Bus auch alle MCUs flashen lassen.
Du gehst aber schnell zur Sache. ;-)
Wenn die CPU/MCU auf einer eigenen Platine untergebracht ist und die Adaption nicht fix
für diese Platine vorgesehen ist wahrscheinlich nicht. Ich für meinen Teil würde nur ungern eine weitere große Platine, eine habe ich ja schon gekauft und werde sie nicht verwenden, mit all dem drum und dran entsorgen wollen nur weil ich später mal auf eine neuere CPU Generation umsteigen möchte und die Platine eben nicht mehr kompatibel ist.Was nicht unbedingt zusammen gehört, z.B. Stromversorgung und Ladung, und was aufgrund des Zeitfaktors, z.B. die Encoder, nicht von der Main verarbeitet werden muss sollte getrennt werden. Wo Störungen aufgrund langer Leitungen ein Problem darstellen sollte man auch darüber nachdenken ob ein kleiner Mini (kostet nicht mal 2 Euro) in der Nähe der Sensoren nicht die bessere Wahl ist.
Ist diesmal etwas kürzer geworden aber ...
Grüße
Rajiva
Zuletzt bearbeitet von einem Moderator:
kurzschuss
Administrator
Hallo Boilevin
Ich habe mal ein kleine Video gemacht wo man sehen kann wie das Ardumowerprojekt geöffnet wird und der Schaltplan dargestellt wird.
I once made a small video where you can see how the Ardumower project is opened and the circuit diagram is displayed.
https://youtu.be/b_e53si_rfU
Gruß
Uwe
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/1259/ArdumowerSchaltplanV1.3.pdf/
Ich habe mal ein kleine Video gemacht wo man sehen kann wie das Ardumowerprojekt geöffnet wird und der Schaltplan dargestellt wird.
I once made a small video where you can see how the Ardumower project is opened and the circuit diagram is displayed.
https://youtu.be/b_e53si_rfU
Gruß
Uwe
Attachment: https://forum.ardumower.de/data/media/kunena/attachments/1259/ArdumowerSchaltplanV1.3.pdf/
Zuletzt bearbeitet von einem Moderator:
Hi all
Did everyone know this board
It's seems to be compatible with DUE .
ShieldBuddy TC275 https://www.rs-online.com/designspark/bringing-multicore-to-the-arduino-world-with-shieldbuddy-tc275 Perfect for the v1.3 board (except the price :S )
Cool the multiple loop loop1 loop2 and memory share no ?
By.
Did everyone know this board
It's seems to be compatible with DUE .
ShieldBuddy TC275 https://www.rs-online.com/designspark/bringing-multicore-to-the-arduino-world-with-shieldbuddy-tc275 Perfect for the v1.3 board (except the price :S )
Cool the multiple loop loop1 loop2 and memory share no ?
By.
Nice piece of Hardware
Aber wieder zurück zur Diskussion.
Mich würde auch mal Interessieren, wie das Restlich Team das sieht, was sagen Marcus und Uwe dazu ? Was sagen die anderen User ?
Um nochmal zu separaten Modulen zurück zu kommen, das stimme ich Rajiva zu.
Die Stromversorgung/Energiezentrum sollte möglichst flexibel ausgelegt werden um die Verschiedene Akku Typen zu unterstützen und auch die Verschiedenen Betriebsspannungen, hier bietet sich ein eigenes Board an, ebenso
bei Rechenaufwendigen, Zeitkritischen Routinen wie z.B. Perimetererkennung, Odometrie oder IMU, wenn dies nicht vom Main Processor ohne Einbußen erledigt werden kann.
Da die die Perimeter Erkennung eine Basis Funktion ist, sollte diese sollte diese auch auf dem Board Integriert sein. Odometrie, Messermodulation sind Optional und könnten eher ausgelagert werden, dies würde dann auch wieder den Einsatz des Mega möglich machen, den bei der jetzigen Konfiguration, Messermodulation und Odometrie auf einem Interrupt, kann der Mega nicht mehr andere Aufgaben erledigen.
Aber wieder zurück zur Diskussion.
Mich würde auch mal Interessieren, wie das Restlich Team das sieht, was sagen Marcus und Uwe dazu ? Was sagen die anderen User ?
Um nochmal zu separaten Modulen zurück zu kommen, das stimme ich Rajiva zu.
Die Stromversorgung/Energiezentrum sollte möglichst flexibel ausgelegt werden um die Verschiedene Akku Typen zu unterstützen und auch die Verschiedenen Betriebsspannungen, hier bietet sich ein eigenes Board an, ebenso
bei Rechenaufwendigen, Zeitkritischen Routinen wie z.B. Perimetererkennung, Odometrie oder IMU, wenn dies nicht vom Main Processor ohne Einbußen erledigt werden kann.
Da die die Perimeter Erkennung eine Basis Funktion ist, sollte diese sollte diese auch auf dem Board Integriert sein. Odometrie, Messermodulation sind Optional und könnten eher ausgelagert werden, dies würde dann auch wieder den Einsatz des Mega möglich machen, den bei der jetzigen Konfiguration, Messermodulation und Odometrie auf einem Interrupt, kann der Mega nicht mehr andere Aufgaben erledigen.
Hi Stephan.
Hope Google translate correctly (my and your) post :lol: .
In fact i really don't understand why you wan't to put a Mega into the V1.3 board .
The Mega work well with the 1.2 Board so for me if you buy a new PCB please change also the Mega by a Due.
I could be agree with you for the batery because there is a big difference between Li-Ion and Lead Acid or other type in charging and protecting method.
But for the Perimeter and Odo i am not agree and i don't understand your problem.
I use a Due on the V1.2 board and test ODO at very high speed without any problem 2880 ticks per rev at 25rpm .So if you do not want to run behind your lawnmower normaly no problem.
Not sure the 'ODOTAILER 4017 pcb' in V1.3 is mandatory ,but why not.
The perimeter and ADC work very well in background with the Alexander Sunray Class, i only have a little doubt for the motor sense of MC33926 (not very stable but need to be confirm)
The one coil perimeter reading can be solve in 10ms so each 5 mm on a mower running at 0.4 Meter/Sec.
So for me all is OK With only one DUE board.
The only board i think it's good to connect to the Arduino is a Raspberry PI for use it with Lidar,Camera,Screen,Computing Speed,Stockage etc....
Now for the V1.3 my little doubts are:
Complexity for Non-electronic person ??.
SMD Soldering and testing ??.
Price if SMD on board ??.
For the rest everything has been perfectly reflected, i thinks Uwez or all the people who worked on it did a tremendous and incredible job so again congratulation.
By a good week end.
Google try to translate.
Hallo Stephan.
Ich hoffe Google korrekt übersetzen (meine und Ihre) Post.
In der Tat ich wirklich nicht verstehen, warum Sie ein Mega in die V1.3-Platine setzen wollen.
Die Mega funktionieren gut mit dem 1.2 Board, also für mich wenn Sie eine neue Platine kaufen, ändern Sie bitte auch das Mega by a Due.
Ich könnte mit Ihnen für die Batterie zustimmen, weil es einen großen Unterschied zwischen Li-Ion und Blei-Säure oder andere Art bei der Aufladung und Schutzmethode.
Aber für den Perimeter und Odo bin ich nicht einverstanden und ich verstehe Ihr Problem nicht.
Ich benutze eine Fällig auf der V1.2-Platine und teste ODO bei sehr hoher Geschwindigkeit ohne jedes Problem 2880 Ticks pro Umdrehung bei 25 U / min. Also, wenn Sie nicht möchten, dass hinter Ihrem Rasenmäher normal kein Problem.
Ich bin nicht sicher, dass die 'ODOTAILER 4017 pcb' in V1.3 obligatorisch ist, aber warum nicht.
Die Perimeter und ADC arbeiten sehr gut im Hintergrund mit der Alexander Sunray Klasse, ich habe nur ein wenig Zweifel für den motorischen Sinn von MC33926 (nicht sehr stabil, aber muss bestätigt werden)
Die eine Spule Perimeter lesen kann in 10ms so alle 5 mm auf einem Mäher mit 0.4 Meter / Sekunde lösen gelöst werden.
Also für mich ist alles OK Mit nur einem DUE-Board.
Das einzige Brett, das ich denke, dass es gut ist, an das Arduino anzuschließen, ist ein HimbeerePI für Gebrauch es mit Lidar, Kamera, Schirm, Rechengeschwindigkeit, Stockage usw. ....
Jetzt für die V1.3 meine kleinen Zweifel sind:
Komplexität für nicht-elektronische Person ??.
SMD Löten und Testen.
Preis wenn SMD an Bord ??.
Für den Rest war alles perfekt reflektiert, ich denke, Uwez oder alle Menschen, die daran gearbeitet hat eine enorme und unglaubliche Arbeit so wieder Glückwünsche.
Durch ein gutes Wochenende.
Hope Google translate correctly (my and your) post :lol: .
In fact i really don't understand why you wan't to put a Mega into the V1.3 board
.The Mega work well with the 1.2 Board so for me if you buy a new PCB please change also the Mega by a Due.
I could be agree with you for the batery because there is a big difference between Li-Ion and Lead Acid or other type in charging and protecting method.
But for the Perimeter and Odo i am not agree and i don't understand your problem.
I use a Due on the V1.2 board and test ODO at very high speed without any problem 2880 ticks per rev at 25rpm .So if you do not want to run behind your lawnmower normaly no problem.
Not sure the 'ODOTAILER 4017 pcb' in V1.3 is mandatory ,but why not.
The perimeter and ADC work very well in background with the Alexander Sunray Class, i only have a little doubt for the motor sense of MC33926 (not very stable but need to be confirm)
The one coil perimeter reading can be solve in 10ms so each 5 mm on a mower running at 0.4 Meter/Sec.
So for me all is OK With only one DUE board.
The only board i think it's good to connect to the Arduino is a Raspberry PI for use it with Lidar,Camera,Screen,Computing Speed,Stockage etc....
Now for the V1.3 my little doubts are:
Complexity for Non-electronic person ??.
SMD Soldering and testing ??.
Price if SMD on board ??.
For the rest everything has been perfectly reflected, i thinks Uwez or all the people who worked on it did a tremendous and incredible job so again congratulation.
By a good week end.
Google try to translate.
Hallo Stephan.
Ich hoffe Google korrekt übersetzen (meine und Ihre) Post.
In der Tat ich wirklich nicht verstehen, warum Sie ein Mega in die V1.3-Platine setzen wollen.
Die Mega funktionieren gut mit dem 1.2 Board, also für mich wenn Sie eine neue Platine kaufen, ändern Sie bitte auch das Mega by a Due.
Ich könnte mit Ihnen für die Batterie zustimmen, weil es einen großen Unterschied zwischen Li-Ion und Blei-Säure oder andere Art bei der Aufladung und Schutzmethode.
Aber für den Perimeter und Odo bin ich nicht einverstanden und ich verstehe Ihr Problem nicht.
Ich benutze eine Fällig auf der V1.2-Platine und teste ODO bei sehr hoher Geschwindigkeit ohne jedes Problem 2880 Ticks pro Umdrehung bei 25 U / min. Also, wenn Sie nicht möchten, dass hinter Ihrem Rasenmäher normal kein Problem.
Ich bin nicht sicher, dass die 'ODOTAILER 4017 pcb' in V1.3 obligatorisch ist, aber warum nicht.
Die Perimeter und ADC arbeiten sehr gut im Hintergrund mit der Alexander Sunray Klasse, ich habe nur ein wenig Zweifel für den motorischen Sinn von MC33926 (nicht sehr stabil, aber muss bestätigt werden)
Die eine Spule Perimeter lesen kann in 10ms so alle 5 mm auf einem Mäher mit 0.4 Meter / Sekunde lösen gelöst werden.
Also für mich ist alles OK Mit nur einem DUE-Board.
Das einzige Brett, das ich denke, dass es gut ist, an das Arduino anzuschließen, ist ein HimbeerePI für Gebrauch es mit Lidar, Kamera, Schirm, Rechengeschwindigkeit, Stockage usw. ....
Jetzt für die V1.3 meine kleinen Zweifel sind:
Komplexität für nicht-elektronische Person ??.
SMD Löten und Testen.
Preis wenn SMD an Bord ??.
Für den Rest war alles perfekt reflektiert, ich denke, Uwez oder alle Menschen, die daran gearbeitet hat eine enorme und unglaubliche Arbeit so wieder Glückwünsche.
Durch ein gutes Wochenende.
:woohoo:Boilevin schrieb:
In my opinion the only disadvantage of a PI is the missing ADCs but the Arduino Mini, connected by I2C, could solve that easily. On the other side there are endless Advantages like a real operating System with large Storage and RAM Memory, Speed, Price, Camera, Ethernet, Bluetooth, real and multiple USB, Multitasking and Multiprocessing, Software Updates while running and much more.
Zuletzt bearbeitet von einem Moderator:
Hallo,
ich schreibe mal auf Deutsch weiter, das fällt mir deutlich leichter sorry,
@Boilevin Das Mega Board soll nur eine Günstige Alternative sein, für User die eine Einfache günstige Variante haben wollen, wir können auch gerne die Mega Unterstützung ganz wegfallen lassen.
Noch besser wäre der Arduino OTTO Star aber leider weiss keiner wann der kommt.
Zum Glück haben die beiden Arduino Fraktionen eine Einigung gefunden.
Das 1,3 wird wohl, nach Uwes Entwurf, deutliche komplexer werden, was dem Due geschuldet und notwendig, ist.
SMD sollen vorbestückt werden, wenn ich Marcus richtig verstanden habe.
Einen Pi über USB Anschließen ist sehr einfach und bringt eine Menge Möglichkeiten, braucht aber beim Design nicht berücksichtigt werden, da keine Anschlüsse dafür notwendig sind.
Ich habe an meinem 1,2 Board auch einen PI dran und kann damit den Mower Steuern und auf die Serielle Konsole zugreifen, was und Zukunft vielleicht auch über die Wlan Schnittstelle möglich ist.
Wenn ich euch richtig verstehe dann sollten wir auch auf ein Zusatzboard für Odometrie verzichten, was aus meiner für einen Due auch OK ist. Der sollte das schaffen.
Den Sinn vom Odometrie Teiler habe ich auch nicht verstanden.
Da werden auf der einen Seite Steigende / fallende Flanken und wenn vorhanden auch noch das zweite Signal ausgewertet und dann wird das ganze herunter geteilt ? Warum nicht gleich nur die Steigende Flanke von einem Kanal auswerten, müsste auch genauer sein.
Den Arduino kann an nicht durch einen Pi ersetzen, da er zu wenig IO Ports hat.
ich schreibe mal auf Deutsch weiter, das fällt mir deutlich leichter sorry,
@Boilevin Das Mega Board soll nur eine Günstige Alternative sein, für User die eine Einfache günstige Variante haben wollen, wir können auch gerne die Mega Unterstützung ganz wegfallen lassen.
Noch besser wäre der Arduino OTTO Star aber leider weiss keiner wann der kommt.
Zum Glück haben die beiden Arduino Fraktionen eine Einigung gefunden.
Das 1,3 wird wohl, nach Uwes Entwurf, deutliche komplexer werden, was dem Due geschuldet und notwendig, ist.
SMD sollen vorbestückt werden, wenn ich Marcus richtig verstanden habe.
Einen Pi über USB Anschließen ist sehr einfach und bringt eine Menge Möglichkeiten, braucht aber beim Design nicht berücksichtigt werden, da keine Anschlüsse dafür notwendig sind.
Ich habe an meinem 1,2 Board auch einen PI dran und kann damit den Mower Steuern und auf die Serielle Konsole zugreifen, was und Zukunft vielleicht auch über die Wlan Schnittstelle möglich ist.
Wenn ich euch richtig verstehe dann sollten wir auch auf ein Zusatzboard für Odometrie verzichten, was aus meiner für einen Due auch OK ist. Der sollte das schaffen.
Den Sinn vom Odometrie Teiler habe ich auch nicht verstanden.
Da werden auf der einen Seite Steigende / fallende Flanken und wenn vorhanden auch noch das zweite Signal ausgewertet und dann wird das ganze herunter geteilt ? Warum nicht gleich nur die Steigende Flanke von einem Kanal auswerten, müsste auch genauer sein.
Den Arduino kann an nicht durch einen Pi ersetzen, da er zu wenig IO Ports hat.