M4 was ist das? Auf den Tensy bin ich gekommen weil er Arduino kompatibel ist aber stanardmäßig sehr viele Analoge I/Os mitbringt, scheint für zukünftige erweiterungen ideal zu sein.
M4 was ist das? Auf den Tensy bin ich gekommen weil er Arduino kompatibel ist aber stanardmäßig sehr viele Analoge I/Os mitbringt, scheint für zukünftige erweiterungen ideal zu sein.
M4 = ARM Cortex M4, hat eine zusätzliche fpu, gibt es von teensy (3.5 und 3.6) und von Adafruit (M4 in den Platinen-Versionen Metro, Feather und ItsyBitsy).Zitat von Graugelb
Übrigens, Riesen-Vorteil, wenn du einen Raspi nimmst für PID statt einen Arduino:
hier hast du pthread mit preemptivem Multithreading zur Verfügung, das ist Gold wert, wenn du mehrere Motoren simultan steuern willst (jeder in einem eigenen PID Thread) - so was gibt es leider nicht bei Arduino, der cooperative-multithreading Scheduler z.B. ist ein absolutes Gemurkse.
Danke für den Input. Du bist also der Meinung bei zu koordinierenden Motoren/Aktuatoren soll ich einen PI für die Steuerung nehmen und direkt die Driver daran anschließen? Den Teensy weg lassen und beim PI mit ExtensionBoards (I²C) die IOs erweitern? Bisher habe ich eben immer von einem Microcontroller ("realtime" Vorteil) hinter einem PI (oder ähnlichem) als Best Practize gelesen. Ein System in dem der PI die z.B. Target-Velocity vorgibt und der Microcontroller über PID dann dafür sorgt das diese erreicht wird.
ja, genau so.
Ich selber habe für meinen Pi stapelbare Extension-Boards (Dexter BrickPi3, per SPI) für Encodermotoren mit M0-cpus (mit onboard-H-Brücken für je 4 Encodermotoren, max. je 1A pro Encodermotor, per Zusatzschaltung allerdings auch stärkere H-Brücken ansteuerbar).
Dabei können diese sogar PD per multithreading ganz alleine von sich aus (eigene Firmware mit Python oder C++ API).
Es gibt solche stapelbaren HATs/Shields auch fertig von Adafruit (nur Python API) - oder du baust sie selber.
ARM Cortex M0 cpus sollten die HATs aber schon haben.
Danke für die Antwort. OK, verstehe, das sind dann aber Controller mit eigener Logik und nicht nur einfache Driver HATs. Meine Idee war da eben diese Produkte aus Teensy und Driver "selbst zu bauen", um mehr Kontrolle zu bekommen (z.B. Position eines Aktuators, beeinflusst PID Werte eines Zweiten - Erklärung: Ist der Manipulator Arm ausgetreckt und wird mit Hoher Nutzlast gefahren so hat es der Aktuator an der Basis mit ganz anderen Kräften zu tun, als wenn mit wenig Nutzlast auf kurzen Hebel gearbeitet wird.) und vor allem viele Motoren darüber steuern zu können (so ganz schnell wie beim Balance-Bot müssen die bei mir nicht sein). Hast du Know-How, Keywords oder Links wieviel Motoren mit einem Teensy koordiniert gesteuert werden können und in welcher Qualität (Latenz)?
Gibt es Threads, Youtube, Blog, Github, oder so zu deinem Build-Projekt, sonst kommen da jetzt noch mehr Fragen in mir hoch.
also, da jeder meiner HATs mit M0 je 4 Encodermotoren steuern kann mit je 2 Pins für Encoder und mind. je 2-3 Pins für die H-Brücken => 4*(2+2)=16 bzw. 4*(3+2)=20 Pins, denke ich, dass das auch schon etwa das Limit ist.
Ob du jetzt die M0 Rechenpower auch noch nutzt für komplexere Regelungen, ist fast, aber nicht ganz zweitrangig, denn wenn du alle raw Einzeldaten zur Steuerung der 4 Rotationsencodermotoren per I2C hin-und herschaufeln willst, brauchst du schon eine seeeehr schnelle Anbindung. Geht aber, habe ich prinzipiell auch schon gemacht, für PID reicht prinzipiell eine 10ms-Regelungsschleife.
Teeny ist ja aber != Teensy, es gibt die mit sehr unterschiedlich leistungsfähigen Prozessoren. Ein 3.2 mit M0 sollte schon sein, wie gesagt.
Blogs gibt es keine mehr, das alte Forum, in dem ich es gepostet habe, ist offline, und an dem einzigen Video kann man nicht so schrecklich viel erkennen:
https://www.youtube.com/watch?v=IBvyu2-AAKM
Ich könnte es zwar noch hier ins Forum portieren, das ist mir aber wegen der umständlichen und Datenmengen-begrenzten Forumssoftware zu aufwändig. Anfragen dazu hat der hiesige Forums admin noch nicht einmal beantwortet.
Danke für die Antwort. Ich dachte an einen Teensy 3.5. Auf den Teensy Weg bin ich gekommen weil das ganze über ROS laufen soll, und da gibt es bereits eine Anbindung für den Arduino und der Teensy sollte da kompatibel sein. Andere Controller schauen da nach ziemlich viel Arbeit aus. Beim Teensy brauche ich auch keinen I²C da der selber mehr als genug IOs ab Werk besitzt (direkt PWM to Driver) und über USB? mit dem Roscore Computer (dachte an PI3, kann dann für Pathplanning, LIDAR etc. auch was größeres werden in Zukunft) verbunden ist.
Blöde Idee?
Berechtigungen
Zitieren
Lesezeichen