Hey,

Das Konzept mit der dezentralen Regelung finde ich auch sehr gut, so kann man alles recht übersichtlich halten. Besonders interessant finde ich ja die Integration der Elektronik mit dem Motor, ich hätte es wahrscheinlich eher so gemacht, dass die Elektronik irgendwo in der Nähe des Hauptcontrollers liegt und dann Kabel zum Motor und Sensor gehen, so hätte man aber nur Versorgungsleitung und Busleitung, die man dann wohl auch einfach hintereinander hängen könnte. Verringert den Verkabelungsaufwand schön
Die Platine direkt am Motor unterzubringen war - für meine Begriffe - in mehrerlei Hinsicht nur folgerichtig. Erstens ging es ja wie gesagt um ein modulares Konzept. Wenn alles klappt und funktioniert, habe ich eine in sich abgeschlossene Einheit, die man so wie sie ist auch an anderen Stellen einsetzen kann. Weil ich den AS5048 als Encoder verwenden wollte (interessierte mich weil ich mal den AS5045 mit SSI im Einsatz hatte, hatte außerdem noch Samples davon), war klar, dass ich eh eine Platine brauche, die sich über dem Abtrieb des Getriebes befinden muss. Und weil es natürlich auf eine präzise Ausrichtung des Sensors ankommt, war's auch irgendwie logisch, die Schraubenlöcher im Getriebekasten zur Befestigung zu verwenden, die sind nämlich sehr genau zu dem Lager der Abtriebswelle ausgerichtet. Außerdem hätte ich es nicht so schön gefunden, die recht hochfrequente und leistungsstarke PWM für die Motoren über unnötig lange Kabel zu verlegen. Ich hab quasi keine Ahnung von EMV, aber intuitiv würde ich sowas vermeiden, wenn's anders geht. Umgekehrt hätte ich auch das 2 MHz SPI über längere Strecken "frei fliegend" verlegen müssen, wenn ich nur den Sensor am Motor gehabt hätte und den Rest zentral. Auch das ist sicher machbar, einfacher ist es aber vermutlich doch, auch das lokal zu lassen. Die Verkabelung ist so eigentlich auch recht schmerzfrei: Es gibt den Stromversorgungsanschluss für den Motor als Schraubklemme und einen Flachbandkabelanschluss für die Logikversorgung und den Bus. Weil der Bus I2C ist (s.u.), kann man mehrere von den Antriebseinheiten auch als Daisy-Chain hintereinander hängen wenn man will, oder eben sternförmig vom Master - das habe ich jetzt hier geplant.

Wie machst du das eigentlich genau mit der Datenkommunikation? Gerade da hatte ich irgendwie Probleme mit, weil ich da einfach nicht weiß, was da gut geeignet wäre.
Tja, das ist auch so ein Thema, gerade für größere Roboter ... Wollte immer schonmal einen Thread dazu hier eröffnen, mache ich vielleicht bald mal . Weil es praktisch für mich gut klappt, verwende ich für solche Zwecke seit mehreren Jahren I2C. Das ist natürlich kein Feldbus, aber weil er relativ wenig overhead hat und auch low-level gut zu beherrschen ist, ist das für meine Zwecke eine gute Sache (ich brauche idR keine allzu großen Bandbreiten). Im Endeffekt ist der I2C auch erstaunlich robust - meiner unmaßgeblichen Erfahrung nach. Ich mache die Pull-Ups immer möglichst klein, dann funktioniert das sogar über längere Kabel. Meistens baue ich in das Protokoll noch eine minimale Fehlerkontrolle (CRC), damit ist es dann recht stabil. Diesmal habe ich auf der Platine noch einen PCA9600 vorgesehen, der macht aus dem I2C einen differentiellen Bus, den man quasi als Feldbus einsetzen kann. Ich habe noch keine Erfahrung damit, und mich bisher ehrlich gesagt auch nur oberflächlich eingelesen. Dieses Projekt war mal eine Möglichkeit ein wenig praktische Erfahrung mit dem Baustein und dem Konzept zu sammeln ...

Sind die Regler-Controller auch über den Bus parametrierbar?
Das ist ja nur eine Frage der Firmware

Also über die Frage eines geeigneten Busses für (größere) Roboter würde ich durchaus gerne - ggf an anderer Stelle - nochmal diskutieren, auch wenn für dieses Projekt die Wahl auf I2C gefallen ist.

Gruß
Malte