Think Modular

zum einbinden in den Arduino-Quelltext braucht man:


#include "serial.h"


zur Initalisierung der seriellen Schnittstelle:


Serial.begin(bps);


hier ein anderes Beispiel: https://www.arduino.cc/reference/en/.../serial/begin/


Zum Schicken von Daten, Serial.write() oder Serial.print(). Zum Empfangen Serial.read(). So weit mir bekannt, kann jeder Teilnehmer jederzeit senden und jederzeit empfangen.
Man kann noch eine Funktion angeben, die dann aufgerufen wird, wenn Daten eingetroffen sind (wenn man nicht dauernd nachschauen will).
Wenn die Funktion dann aufgerufen ist, macht man nichts anderes, als Serial.available() - ob und wieviele Daten verfügbar sind - und dann liest man die.


Ich nutze die Sachen auch nur, muss ich nicht alles selber programmieren. Ist der Vorteil daran.
Wie schnell so ein Datenaustausch am Ende ist, teste ich, wenn ich es wissen will, im Programm selber. Beim Hexapod war es schnell genug, um flüssige Bewegungen hervorzubringen, trotz zwischendurch Positionsdatenblöcke für bis zu 3 oder 4 Beine am Stück übermittelt wurden. Also für etwa 9 Servos. Vielleicht auch mal mehr. Kann ich jetzt aber nicht mehr überprüfen, weil das Gerät demontiert ist.


Ob wir hier echte Arduino-Freaks haben?




MfG

--------------------------------------
Nachtrag 27.11.2020:

Das mit der "serial.h" will ich so nicht stehen lassen, weil es offenbar nicht richtig ist. Heute bin ich dazu gekommen, dies direkt auszubrobieren. Wie ich da auch "serial.h" kam? - Weiß ich auch nicht mehr. Wenn ich es benötige, füge ich persönlich "HardwareSerial.h" per #include hinzu. Da ich gerade jetzt damit zu tun habe, hier nur die Richtigstellung.

Zitat:

---

Zitat von Defiant

Spannung & Strom werden von einem A/D-Pin eines AVR gemessen, dort in Volt & Ampere umgerechnet und per I2C an den Einplatinencomputer gegeben. Die ROS-Node holt diese Information aus den entsprechenden I2C-Registern ab. Hier ist der Quellcode für die Implementierung in C und Python. Der ROS-Welt werden die Werte einmal als diagnostics und einmal als BatteryState-Message zur Verfügung gestellt.

---

Super, ich kann kein ROS, Du hast keine Lösung für Lithium-Zellen. Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben:
Sieht auf der Softwareseite fast schon so kompatibel aus, als ob ich Dir eine Mitschnittdatei aus meinem Projekt schicken könnte, wo Du Dir in ROS die Telegramme auseinander fummelst und die entsprechenden Nodes meines Powermoduls anbindest.

Es wurde ja auch viel entwickelt um ROS unabhängig von einer spezifischen Hardware zu bekommen. Ich könnte zumindest unterstützen, wenn du für deinen Roboter eine ROS-Anbindung haben möchtest. Allerdings wären die Spannungs- und Stromwerte nicht meine oberste Priorität, sondern der Antrieb.

Zitat:

---

Zitat von Holomino

Abgesehen davon, dass wir weder über Ströme, Spannungen noch Stecker gesprochen haben

---

Ja, sollte zuerst gemacht werden. Software lässt sich viel leichter ändern und an verschiedene Gegebenheiten anpassen als Hardware.

Als Freak würde ich mich nicht gerade bezeichnen, aber ich mach viel mit der seriellen Schnittstelle (die ist einfach praktisch).

Zuerst @Moppi: du musst die serial.h nicht extra einbinden.
Das macht die IDE sowieso.
Wichtig ist nur, diese Schnittstelle auch zu starten:
Serial.begin(115200);
Tipp: wie hoch man hier mit der Baudrate wirklich gehen kann, einfach ausprobieren, das geht oft noch deutlich höher, wenn mans eilig hat)
Teilweise muss man aber auch mal runter gehen, beispielsweise, wenn man BT-Module dazwischen hat, und der Empfang nich mehr so gut ist.

Und: man kann diese Kommunikation auch wieder beenden mit
Serial.end();
Das macht beispielsweise dann Sinn, wenn man die Pins gleichzeitig für _irgendwas_ anderes benutzen will.

Ja- das geht auch asynchron.
Beide Teilnehmer haben einen (in der Grösse definierbaren) Empfangspuffer. Dort landet das, was die Gegenstelle spricht, erstmal ohne weiter beachtet zu werden. Man muss halt aufpassen, dass dieser Puffer nicht überlaufen kann, daher auch die Möglichkeit, den grössenmässig zu definieren.
Wenn der Empfänger dann Zeit hat, kann er nachsehen, ob da was ist und was...
Eine "Rückkopplung" gibt es nicht- der Sender kann senden, was und wie oft er will- er weiss _nicht_, ob es auch ankommt!
Das kann man aber natürlich in Software lösen, wenn man beide Leitungen benutzt.
Dadurch kriegt man die ganze Sache eigentlich so robust, wie man sie haben will.

Man kann das auch abspecken- wenn der Empfänger _nur_ Empfänger zu sein braucht (weil er nix zu melden hat) kann man eine der Leitungen auch weglassen.
Das funktioniert, hat aber den Nachteil, dass man eben keine Sicherheit hat, dass auch alles richtig angekommen ist.
Manchmal braucht man die aber auch nicht.
Im Grunde kann man damit sogar mehrere Rechenknechte kommunizieren lassen (nur nich jeden beliebig mit jedem).
R1 kriegt eine Strippe an Tx, die führt zu Rx an R2. Der bekommt nun eine an Tx, die zu Rx an R3 führt...und so weiter.
Da keiner der Rechner weiss, mit was er da eigentlich redet, funktioniert das tadellos- man könnte nun noch R3 mit R1 verbinden und schon weiss R1, ob seine Kommandos wirklich befolgt wurde...
Abenteuerlich, aber das geht.
Auch möglich: ein Sender gibt Befehle an _mehrere_ Empfänger.
Die kann man einfach alle mit ihrem Rx an den TX des Masters hängen.
Logischerweise kriegen die alle dann das Gleiche....dort könnte man, wenn man Feedback will, auch noch Kommandos einbauen, bei denen der Master den Slaves sagt, von wem er eine Antwort wünscht- man muss halt sicherstellen, dass alle anderen dann die Klappe halten.
Hier kann man sich lustige Protokolle basteln...

Aufpassen muss man aber bei vielen Arduinos doch etwas: die serielle Schnittstelle (man kann die auch in Software nachbilden, das funktioniert...manchmal..auch) wird zugleich zum programmieren benutzt.
Viele Arduinos (Uno, Nano, ProMini...) haben aber nur die eine- man sollte also ein anderes Gerät, was da dann im Betrieb dran hängt, zum schweigen bringen, ehe man versucht, ihn zu programmieren.
Es reicht, wenn man die Leitung, die zu Rx geht, unterbricht.
Die Tx muss nur raus, wenn das dort dran hängende Gerät nicht "mithören" darf (Arduino sendet auch beim programmieren was retour, damit der Rechner, von dem aus er programmiert wird, weiss, dass es klappt).
Es geht auch, wenn das angeschlossene Gerät einfach die paar Sekunden die Klappe hält- weil die Dinger eben _nicht_ unterscheiden können, woher das Gesabbel eigentlich kommt.
Schöner ist hier der Mega2560- der hat drei der Dinger in Hardware.
Da kann man recht sorglos basteln...

Hift das weiter?

Zitat:

---

Zitat von Rabenauge

Zuerst @Moppi: du musst die serial.h nicht extra einbinden.
Das macht die IDE sowieso.

---

Bitte beachte die Fragestellung zuvor! Sinngemäß: wo finde ich den Code dafür, welche Datei?

MfG

PS: Bin heute etwas empfindlich dahingehend. Habe ein MRT an die Uniklinik geschickt, zum Termin in der Orthopädie, was ich bekommen habe ist ein ein Chirurg, der Einzelheiten der MRT nicht erläutern konnte, weil nicht sein Fachgebiet. Weiß nicht, ob das gerade gesellschaftlich in Mode ist, einfach mal irgendwas zu machen, anstatt das Richtige? Jetzt fange ich noch mal von vorne an, wieder neuer Termin... usw. Vielleicht können wir hier wenigsten auf so "unbedeutende Kleinigkeiten" achten?


--------------------------------------
Nachtrag 27.11.2020:

Das mit der "serial.h" will ich so nicht stehen lassen, weil es offenbar nicht richtig ist. Heute bin ich dazu gekommen, dies direkt auszubrobieren. Wie ich da auch "serial.h" kam? - Weiß ich auch nicht mehr. Wenn ich es benötige, füge ich persönlich "HardwareSerial.h" per #include hinzu. Da ich gerade jetzt damit zu tun habe, hier nur die Richtigstellung.

Letzter Punkt dazu:

Die IDE bindet nicht zwangsläufig eine "serial.h" oder richtiger die "HardwareSerial.h" ein. Oder anders ausgedrückt: "Serial" ist nicht zwangsläufig vorhanden, also nicht immer im aktuellen Scope deklariert. Es gibt Ausnahmen. Und weil ich es gerade in der Mache habe, hier ein Beispiel, wie das z.B. in der der Arduino-IDE ausschaut, wenn es eben nicht vorhanden (eingebunden) ist:

Code:

---

xFunktion.cpp:7: error: 'Serial' was not declared in this scope


  Serial.println("funktion 1");


  ^

---

Wie kann man das Lösen? Zum Beispiel so:

Code:

---

#include <HardwareSerial.h>
extern HardwareSerial Serial;

---

Zitat:

---

Zitat von Defiant

..., sondern der Antrieb.

---

Ein bisschen spooky (für mich):
Ich nehme mal an, dass SetVelocity(1, PI/2) aus Deinen Quellen den Robbi einen Kreis fahren lässt?
Ist das die einzige Möglichkeit in ROS, die Bewegung zu steuern? Ober gibt's für Omniwheels, Synchrodrive und Spinnen noch andere Bewegungsanweisungen?

Ja, wobei 1m/s translation und 90°/s rotation schon sehr schnell ist. Ich fahre normal eher mit 20-50cm/s und 20°-60°/s.

Ist denn dann z.B. das Bremsen vor einer Kurve beim Folgen eines Pfades Bestandteil des Pathfinders (oder Pathfollowers)?

Bei dem base_local_planner den ich verwende nicht. Es gibt noch diverse andere Planner, die man stattdessen verwenden kann. Ob einer von denen vor der Kurve bremst kann ich nicht sagen - hatte das Problem noch nicht. Es gibt aber die max Beschleunigung für Translation und Rotation, d.h. der Planner wird kein Kommando von 0°/s auf 90°/s absetzen, sondern die Geschwindigkeit Schrittweise erhöhen.

Hmm, ich kann mir schwer vorstellen, einer Spinne, die sich über Hindernisse tastet, Geschwindigkeitsvorgaben zu machen. Ebensowenig kann ich mir vorstellen, einem Synchrodrive mit dAngle/s das seitwärts losfahren beizubringen.

Kann es sein, dass z.B. mit https://wiki.ros.org/follow_waypoints auch die Interpolation des Pfades über die Angabe von Zwischenpunkten (-posen) möglich ist? (Die könnten Spinne oder Synchrodrive-Roboter ja zumindest linear ansteuern).