Ich plane wieder ein keines Projekt bei dem ein kleines "Robo-Car" entstehen soll. Merkmale des Autos sind (viele Sachen die "parallel" laufen sollten!!!):
LCD Display um Sensorwerte, Texte und 2D Grafiken auszugeben
Verschiedene Sensoren nutzen wie ,Temperatur, IR, Ultraschall, Laser "Lidar Lite" usw.
WLAN Verbindung (Steuerung von PC/Notebook & Reichweite +100m bzw. durch Wände)
Nema 17 Schrittmotoren als Antrieb ansteuern + ggf. andere (Schritt-)Motoren
Mehrere Servos steuern (Lenkung, kleiner Roboterarm zum aufheben von kl. Gegenständen usw.)
Meine Befürchtungen und Probleme:
So, das größte Problem in meinen Augen ist, dass vieles parallel laufen soll wie z.B. Steuerung der beiden Schrittmotoren + auslesen der Befehle die über Wlan gesendet werden + Direktausgabe über das Display (auch 2D Grafiken) + auslesen von Abstandssensoren usw.
Nun frage ich mich nun ob der Arduino Mega 2560 dafür noch wirklich ausreicht.
Bei einem ähnlichen Projekt habe ich damals schnell erfahren müssen, dass der Mega in Sachen Rechnerleistung doch etwas limitiert ist.
Damals hatte ich z.B. Probleme beim gleichzeitigen darstellen von 2D Grafiken und dem Ansteuern von Schrittmotoren. Hierbei sollte ein Dreieck die Fahrrichtung anzeigen wobei die Drehung des Dreieck anhand von Sin/Cos Berechnungen durchgeführt wurde welche die Ansteuerung der Schrittmotoren verlangsamten bzw. die Darstellung der 2D Grafiken wurde zur Diashow.
Meine Fragen nun:
Ziel ist eben, dass so viel wie möglich reibungslos parallel gemacht werden kann. Reicht dafür ein Arduino Meag 2560 noch aus oder sollte ich mich nach einem leistungsstärkeren Board wie dem Arduino Due umschauen?
Wenn der Arduino Mega ausreichen sollte, habt ihr da ein par Stichworte nachdem ich suchen kann um mehr Infos darüber zu erhalten wie man so etwas "effizient" beim Mega umsetzt?
Wenns doch ein Arduino Due werden soll, wie sieht es da mittlerweile mit der Kompatibilität der verschiedenen Libraries aus? Muss da vieles von Null auf programmiert werden? Hat da jemand positive/negative Erfahrungen gemacht?
Ich würde auf jeden Fall graphische Darstellungen (und WLAN...) von zeitkritischen Steuerungsaufgaben trennen, also zwei (oder mehr) Controller verwenden. Dann läßt sich auch leichter ein als zu langsam befundener Controller gezielt durch einen schnelleren ersetzen, oder seine Aufgaben auf mehrere Controller verteilen (skalierbare Architektur).
Eventuell einen RasPi für die Anzeige etc. verwenden, der hat ja schon jede Menge Peripherie an Bord, die man bei den Arduinos noch separat hinzufügen müßte.
Funktionen wie digitalRead und digitalWrite kann man mit direkten Port-Zugriffen beschleunigen, die dürften aber eher nicht das Problem sein.
So wild ist das bissel Grafik auch wieder nicht.
Und: wozu braucht man das im Betrieb? Kaum jemand wird neben nem Fahrzeug her rennen, um das Display abzulesen- Werte, die interessieren, kann man ja bequem am Laptop sehen, wenn man eh Wlan hat.
Mein Monster gibt während der Fahrt auf dem Display gar nix aus- sondern nur im Stand, oder zu Debug-Zwecken mal (hab keine Datenverbindung an Bord).
Und im Stand wird von dem ganzen anderen Gedöns nicht viel gebraucht, da ist allemal Zeit für Spielereien.
Für grafische Zeiger usw. gibt es tolle, sparsame Algorithmen, z.B. Bresenham (und Abwandlungen), die benötigen keine nennenswerte Rechenleistung.
Ja, Schrittmotoren- nen wirklichen Sinn machen die bei Fahzeugen eher selten. Fressen aber ne Menge Ressourcen, die man anderswo gut brauchen könnte.
Ich würd einfach mal nen Mega her nehmen, und die geplanten Programmteile rauf packen. Dann kann man schauen, wie er noch zurecht kommt damit.
Ggf. kann man ja das Fahrwerk über nen ProMini oder sowas steuern, der kann auch gleich noch Akkus überwachen usw.
Das mit den Algorithmen hört sich interessant an (Bresenham usw.)
Zu der Frage warum Schrittmotoren. Das ist ganz einfach da sich das Auto parallel auf dem Computer in einer 3D Simulation bewegt. Ich möchte also möglichste genaue bestimmte Positionen anfahren. Schnell muss es gar nicht sein (wobei das Auto durch das eingesetzte Getriebe schon viel zu schnell werden kann :D)
Das Display hat tatsächlich keinen tieferen Sinn. Es ist lediglich dazu gedacht um am Anfang bestimmte Infos über den Verbindungsaufbau usw. auszugeben (ggf. auch abzufragen). Ansonsten sollen einfach hübsche 2D Demos ablaufen wenn das Teil iwo rumsteht oder sonst was - just for fun halt. Das mit der Fahrrichtung fand ich damals ne ganz nette Sache. Grad wenn sich das Teil kein Stück bewegte aber man am Display trotzdem sehen konnte, dass es sich eigentlich bewegen sollte.
Die Idee mit mehreren Controllern ist mir heute morgen auch mal durch den Kopf gegangen ...hatte schon an 2 Arduino Nano gedacht.
Mal sehen was sonst noch für Anregungen reinkommen.
-> Interessant wären auch ein par Meldungen zum Arduino Due. Würde der das alles mit seinen 84 MHz problemlos wegstecken oder nicht ...oder hätte ich damit nur Ärger da ggf. kaum Libs funktionieren? Hat da jemand Erfahrungen?
Ich arbeite gerade mit dem Due (Steuerung für einen Laserplotter)
Verwende bis jetzt aber keine fremde Lib's. Viele Lib's sind aber schon Due kompatibel.
Kann ansonsten nichts Negatives über den Due sagen, die schnellere Pattform im Vergleich zu den AVR deutlich zu spüren.
Etwas gewöhnungsbedürftig ist die 3,3V Logic, und das die PIO's wenig Strom können.
Bei mir ist der Rest 5V (Servoendstufen z.b.), hier mussten Levelshifter gebaut werden.
Ist aber keine große Sache.
Wenn du die Vorteile des Due komplett nutzen willst, dann verwende auch hier keine Arduino PIO Zugriffe.
Habe mir dafür Funktionen gebaut, für den direkten Register Zugriff. Na ja nicht ganz selbst gebaut, eher zusammengefügt was ich gefunden habe. (Aber schon verstanden)
Der Zugiff auf die ARM PIO's ist komplett anders als die bei den AVR's
Bei meinem Plotter verwende ich den Bresenham für die Geraden.
Bei Kreisbögen im Prinzip die Kreisfunktion (x²+y²=r²), mit Wechsel der schnellen Richtung wenn nötig.
Das lief auf den AVR schon Problemlos, auf dem ARM (Due) sowieso.
Du willst dein Auto nicht etwa via x und y Befehlen steuern - wie schaut die Mechanik dazu aus ?
Patrick_123:
Damals hatte ich z.B. Probleme beim gleichzeitigen darstellen von 2D Grafiken und dem Ansteuern von Schrittmotoren. Hierbei sollte ein Dreieck die Fahrrichtung anzeigen wobei die Drehung des Dreieck anhand von Sin/Cos Berechnungen durchgeführt wurde welche die Ansteuerung der Schrittmotoren verlangsamten bzw. die Darstellung der 2D Grafiken wurde zur Diashow.
Komplexe Berechnungen weit Abseits von +/-/* dauern auf den Atmegas irsinnig lange. Deshalb sollte man hier so weit wie möglich optimieren. Eine sehr verbreitete Möglichkeit ist die Verwendung von LookUp-Tabellen, wo die Sinus-Werte vorberechnet sind.
Danke, auch ne gute Idee diese look-up Tabellen.
Hab zum Testen mal den Due geholt.. Bin erstaunt wie einfach die bisher getesteten Servo und TFT Beispielcodes vom Mega auf den Due kopiert werden konnten :o ...funktionieren ohne Probleme. Beim Display-Beispielcode sieht man auch schon gleich am Bildaufbau, dass der Due um einiges schneller ist... werd mal weiter testen.
(Aber schon verstanden)