"Smarte" ESC/Steuerung auf Arduino Basis

Nachdem ich den spannenden Thread von finger.im.ohr kurzzeitig etwas zweckentfremdet hatte (Sorry dafür!), und von IBF in diese Richtung hier gestupst wurde, hier ein kleiner Thread zum Thema Arduino als ESC.

Wer sich für das Thema Fernsteuerung per Arduino interessiert kann hier die Antweight Projekte von Finger im Ohr finden: Arduino Ants (AA)

Bei meinem Projekt ist der Ansatz genau anders herum: ich habe eine alte 27Mhz Pistolengriff Funke hier und möchte 2 Motoren damit ansteuern, ohne einen extra ESC dafür nutzen zu müssen.

Die Anforderungen der Idee:

- Eingang der Signale vom RC Empfänger

- freie Programmierung der Steuerung (Eingangssignal: Vor/zurück und Links/rechts, Ausgabe an Motoren: Vor/Zurück und Geschwindigkeit als PWM Signal jeweils für linken und rechten Motor)

Da das Projekt aus meiner Restekiste gestartet wurde (und arbeiten mit größeren Bauteilen etwas angenehmer ist für meine grobmotorischen Finger) startet das Projekt mit folgenden Bauteilen:

• Arduino Uno R3
• L298P Motor Shield (wird einfach auf den Arduino aufgesteckt mit identischem Pin Layout
• 2x Getriebemotor 12V

Damit kommen wir schonmal zu den ersten Pros und den ersten Herausforderungen beim Projekt:

Positiv:

• Kosten: Ein Arduino und das Motor Shield liegen in Summe bei ca 30€ für die steuerung von 2 DC Motoren
• Umfang: das Motorshield hat 2 Kanäle für DC Motoren, für einen Roboter also Ideal. Durch die Beschränkung von 12V/2A ist man Leistungstechnisch vermutlich auf Antweight beschränkt, da für alles andere doch stärkere Motoren notwendig sind.
• Freiheiten mit Arduino: vorausgesetzt man ist in der Lage den Arduino selbst zu programmieren, sind die Möglichkeiten hier nahezu unendlich (Regelwerk zur jeweiligen Klasse beachten!). Neben den 2 Motoren sind hier noch massenweise Pins für allerlei Spielereien frei: Lagesensor der automatisch ein Makro startet, um den Bot wieder aufzurichten? Kein Problem. LEDs, die je nach Geschwindigkeit ihre Farbe und Helligkeit ändern? Klar. Ein OLED Display das vor jedem Kampf per USB ein paar Verunglimpfungen für den gegnerischen Bot aufgespielt bekommt? Solange man das Gewicht mitnehmen kann schnell erledigt, usw.
  Wer das auf die Spitze treiben möchte könnte auf diese Weise sogar einen vollautonomen Bot programmieren, bei dem die Fernsteuerung nur noch als on/off genutzt wird. Das übersteigt aber meine Fähigkeiten bei weitem und wird definitiv in diesem Projekt nicht passieren.

Negativ:

• Leistung: Das Motor Shield gibt wie oben schon gesagt max. 2A pro Kanal aus. Damit ist man in der Anwendung stark eingeschränkt. ich habe schon ein paar L298 Module mit etwas mehr Leistung gesehen, aber vergleichbares mit "richtigen" RC Reglern ist mir bisher nicht begegnet.
• Größe: Hier ist aktuell das größte Problem bei meinem Aufbau. Der Arduino ist mit ca 70 x 50 mm für einen Antweight Bot schon kritisch groß. Das Motor Shield wird oben aufgesteckt und hat identische Maße. Hier bleibt wenig Platz für Empfänger, Akku, Motoren und Servos. Das ist aber kein allgemeines KO-Kriterium, da es weit kleinere Arduinos und Motor shields gibt. Damit werde ich mich aber erst beschäftigen, wenn das Konzept als solches auf dem Uno funktioniert.

Soweit mal die Theorie.

Aktuell bin ich soweit, eine kleine Box für alle Komponenten gedruckt zu haben, alles ist verkabelt und zumindest ganz rudimentär bewegt sich auch schon etwas.

Im Laufe der nächsten Tage kommt der aktuelle Stand der Software und dann vermutlich ca 1 Mio Fragen und Hoffnung auf Hilfe von euch

Das ganze soll aber auch nicht unbedingt "meine" Projektvorstellung werden - wer also eine ganz andere Herangehensweise an ein vergleichbares Projekt hat kann den Thread gerne auch nutzen.

Cool, danke. Mit den ATtiny85 kenn ich mich noch überhaupt nicht aus, da muss ich mich mal einlesen was das so genau ist.

Der Motortreiber ist noch etwas schwächer, der ist denk ich keine so richtige alternative. allerdings hab ich auch mittlerweile welche gefunden, die zumindest im zweistelligen Ampere Bereich liegen.
Aber dazu muss erstmal der Code vernünftig laufen.

Das schaue ich mir heut abend nochmal an und teste etwas damit rum und werde dann mal den aktuellen Stand posten - was funktioniert, was nicht und was noch dazu kommen soll

Edit: Oh man IBF , damit überforderst du den IT Laien hier schon mal maßlos. Ich denke ich muss da mal ChatGPT und Google zu Hilfe nehmen, um all das zu verstehen
Aber ist ja auch spannend da neu dazu zu lernen.

Zitat von IBF

Ich bin auch kein IT-ler, sondern Elektrotechniker. Aber im Laufe der Jahrzehnte lernt man dazu.... Bin seit dem Jahr 2002 an dem Bau von Fahrtreglern dran, wird immer weiter verfeinert.... Nur leider sind die Materialkosten so hoch geworden (Platine "Made-in-Germany" kostet halt leider mindestens einen zweistelligen Betrag), dass die Gemeinde lieber China-Zeugs kauft. Sind also Entwicklungen vorwiegend "nur für mich" bzw. dann für die Bots, die bei Publikumsveranstaltungen genutzt werden.

Oben mit der Liste war die Kurzfassung. Fang einfach mal an, poste hier wie Du es machst.... und wenn Du meine Meinung hören willst, dann immer gerne. Hilft ja nicht, wenn ich Dir einfach meinen Quellcode schicke und Du das nachprogrammierst. Soll ja Dein eigenes Baby werden.

(Aktuelles Projekt meinerseits: Ein Ant-Fahrtregler mit aufgestecktem Empfänger. Hat wahnsinnig viele Extras am Waffenkanal, so dass man ihn eigentlich schon als reinen Schaltaktor verwenden kann. Als Gratis-Beigabe dann noch zwei Fahrtregler-Kanäle für Motoren., )

Naja, aber als Elektrotechniker verstehst du wenigstens was die ganzen Kabel da tun Ich bin ausm Bereich Karosseriebau - bei mir beschränkt sich das auf "Mann drückt auf Roboterpanel rum, Roboter bewegt sich zu Blech, WPS Zange macht bzzzzzt"

Ja das mit den Herstellkosten kann ich mir gut vorstellen. Zu den Preisen, bei denen man auf Aliexpress ganze module (kleine ESCs etc.) bekommt, ist hierzulande noch nichtmal der Logistiker bezahlt, der das ding verpackt und weg schickt...

Also zum ersten Stand:

DISCLAIMER: Da ich keine Ahnung von programmieren oder im speziellen C habe ist mein Code eine Mischung aus google, ChatGPT und trial&Error. Für jeden Programmierer besteht die Gefahr eines spontanen Herzinfarkts beim lesen meiner Spaghetti-Codes

#include "makros.h"
#include "debug.h"
#include "RCReceive.h"

const byte PIN_RC1 = 6; // Kanal 1 Eingang, Gas
const byte PIN_RC2 = 7; //Kanal 2 Eingang, Lenkung

// Der Empfänger
RCReceive rcReceiver1;
RCReceive rcReceiver2;

int analogPin1 = 3, analogPin2 = 11; // Analogausgangspins
int digitalPin1 = 12, digitalPin2 = 13; // Digitale Ausgangspins

void setup() {
Serial.begin(9600);

 // Kanäle auf Ausgang
pinMode(3, OUTPUT);
pinMode(11, OUTPUT);
pinMode(12, OUTPUT);
pinMode(13, OUTPUT);
pinMode(6, INPUT);
pinMode(7, INPUT);
pinMode(8, OUTPUT);
pinMode(9, OUTPUT);

// RC Receiver
rcReceiver1.attach(PIN_RC1);
rcReceiver2.attach(PIN_RC2);
  
// put your setup code here, to run once:
}

void loop() {

rcReceiver1.poll();
rcReceiver2.poll();
// nur wenn der Nullpunkt bestimmt worden ist,
// und es keinen Fehler gegeben hat soll die eigentliche Arbeit gemacht werden
if (rcReceiver1.hasNP() && !rcReceiver1.hasError()) {
doWork();
}
else if (rcReceiver1.hasError()) {
  Serial.print("Problem");
// Fehlerbehandlung failsafe oder sowas...
}
}

void doWork() {
// code zur Ansteuerung der Motoren
byte value1 = rcReceiver1.getValue();
byte value2 = rcReceiver2.getValue();

Serial.print("Gas");
Serial.println(value1);
Serial.print("Lenkung");
Serial.println(value2);

Ich arbeite mit der RCReceive Library, da diese eine Nullpunktbestimmung drin hat, den Wertebereich direkt auf 0-255 mapt und auch einen Failsafe, wenn die empfangenen Werte zu weit streuen und als verlorene Verbindung interpretiert werden.

Hier scheint aber auch schon ein Problem zu sein: Laut WIki der library nutzt die poll() Funktion 10 Werte und mittelt diese und kommt somit auf eine verzögerung von 200ms. Das ist schon verdammt lange, wenn danach erst der code weiter geht.

Über die Serial.print funktion sieht das aus, als wäre es viel schneller als bei der Ansteuerung der Motoren, aber vielleicht täuscht das auch?

Die Ausgabe der PWM Werte an die Motoren habe ich dann gestern nochmal komplett über den haufen geworfen, weil das nix war.

Da mach ich mich dann nochmal von vorne dran, sobald ich das Gefühl habe, die Eingangs-Seite läuft vernünftig.

Zitat von IBF

Keine Sorge. Wenn ich in der Arbeit bei unseren Software-Entwicklern beim Code-Review mit dabei war, hatte ich mich auch manchmal gewundert, dass das überhaupt noch funktioniert....

Also, wie gesagt, von Adruino habe ich noch keinen Schimmer. Aber die Bezeichnungen geben gewisse Hinweise auf die Funktion, die hier unter der Motorhaube versteckt ist.

Wenn ein Digitalwert von einem Pin mit 200ms Mittelung gebildet wird, dann ist das eigentlich relativ "unbrauchbar". Ich weiß nicht, ob Dir die Signale, die vom Empfänger rausgehen, geläufig sind? Bzw. was das Timing angeht und wo die eigentlich Nutz-Information versteckt ist?
Wenn das Neuland ist, dann gib' Bescheid, ich mach' dann mal eine Skizze. (=> Ist nicht schwer zu verstehen, aber es muss einfach mal dargelegt werden.)

Also ich hab so ganz grob eine Idee, was dahinter steckt. Das ganze funktioniert ja auch als PWM SIgnal, richtig? Also kein analoger Wert von-bis sondern ein Puls mit einer ganz bestimmten Signallänge bzw breite? Allerdings ist das auch alles irgendwie nebelsuppe in meinem Kopf. So richtig klar ist mir nicht, welches Signal da nun rein geht, was raus kommt und wie das dann von einem Servo, ESC oder eben dem arduino wieder zu einem Wert eingelesen wird.

Das mit dem pulseIn() ist natürlich auch noch ne spannende Variante. Ich sehe schon, ich muss mich glaub ich - wenn das jemals mehr sein soll als n bisl spielerei ohne nutzen - von der fertigen library verabschieden oder diese mal selbst durchgehen und verstehen.

Aktuell weiß ich nur, dass da irgendwie ein Nullpunkt bestimmt wird, die werte auf eine Range von 0 bis 255 gemappt werden und ich über den poll() einen MIttelwert über 10 Messungen als Output bekomme. Und wenn ich das richtig verstanden habe scheint ja eine Messung dann 20ms zu gehen, da die Wertausgabe ja 200ms verzögert sein soll. Aber den COde hinter dieser library hab ich mir noch nicht angesehen.

Interrupts werden dort angegeben als optimale Variante, klappt bei mir aber aus kompatibilitätsgründen nicht (mein Board hat nur 2 Pins die für interrupts geeignet sind und einer der Pins ist gleichzeitig der vom Motorshield genutzt für die Klemme vom Motor).

Du meintest ja, du bist von dieser Variante wieder weg, da es zu viele Probleme gab. Was waren denn die Probleme damit bzw was sind denn die Nachteile von interrupts? Bisher sehe ich immer nur "is besser, weil viel schneller".

Danke schonmal für deine Hilfe - das ist wirklich Klasse!!!

Sooo, sorry das ich so lange nix geschrieben hab, war spontan n paar tage auf Dienstreise und konnte unterwegs zwar lesen, aber da ich keine arduino Software greifbar hatte bin ich nicht so recht damit weiter gekommen.

Danke auf jeden fall, das ganze hat mir schon sehr viel weiter geholfen. das Grundprinzip war mir klar, aber wie nun jetzt die Unterscheidung der einzelnen Kanäle am Empfänger funktioniert war mir nicht klar.

Mit dem wissen machen nun aber auch die 200ms der vorgefertigten software sinn: ein wert 20ms, der gebildete wert ist der mittelwert aus 10 werten --> 200ms dauert es, bis ein wert ermittelt wird.

Und auch klar wird mir jetzt, warum zwar vielleicht die 200ms stimmen, es mir aber so viel kürzer vorkommt, wenn ich diesen wert auslese. es ist ja immer das Mittel der letzten 10 werte, also wenn ich von 0 auf 255 springen würde mit dem input dauert es 200ms, bis er auf genau 200ms kommt, aber alle 20ms wird ein neuer Mittelwert gebildet, das siganl wird dadurch also nicht verzögert, sondern einfach nur gedämpft.

Mit dem wissen konnte ich das auch so nachvollziehen - ist nicht einfach weil ja auch die arduino Ausgabe etwas delay hinzufügt, aber es ist schon erkennbar, dass die Ausgabe bei schnellem gas/bremse etwas "hinterher hinkt".

Nun aber zu der Theorie, wie das ganze dann ausgelesen wird: hier übersteigt das noch etwas meine Fähigkeiten mit Elektrotechnik und Programmiersprachen. Ich hab mir mal den RCReceive Code angesehen und dort verliere ich ziemlich schnell den überblick, was da gemacht wird.

Ich denke fürs erste werde ich nun doch den Code so nutzen (nur das Thema failsafe werde ich mir nochmal genauer ansehen um dann auch sicher zu sein, dass das so passt - muss mal sehen ob ich irgendwie eine störquelle schaffen kann als Test).

Denn was ich ja noch immer nicht hinbekommen habe: die Eingangswerte vernünftig und effizient umrechnen auf motorsignale und dann die motoren korrekt ansteuern.

Ich hab nen ganz kurzen code geschrieben, der einfach nur Vollgas in beide Richtungen und auf der stelle drehen kann - das klappt, ist aber natürlich nicht praktikabel.

Das wird also die nächste Station.

Parallel habe ich allerdings schon mal angefangen mir Gedanken zu einem roboterdesign zu machen, um dann auch was zu haben, dass man in einem Wettkampf einsetzen könnte. Dazu wirds aber vermutlich nen eigenen thread geben, da ich hier eher auf fertige Hardware gehen werde. Denke es ist sinnvoller, das Projekt in 2 Einzel Projekte aufzuteilen und wenn beide Projekte laufen kann man das immer noch zu einem neuen zusammenführen.

Auf jeden Fall erstmal ein riesen Dankeschön an euch beide, ihr habt mich schon weiter gebracht als ich dachte, zu Beginn des projektes überhaupt zu kommen!!!

Vorab mal: ich hoffe ihr hattet ein gutes Wochenende und ganz selbstlos hoffe ich, es wurden en paar Videos von dem Kämpfen gemacht?

Ok, das mit dem Failsafe hatte ich mir komplizierter vorgestellt. Das klappt sehr gut, wenn er jetzt aus seinem Stack von 10 Werten mindestens 3 findet, die außerhalb der Range sind geht er auf einen anderen Programmcode, der dann die LED auf dem Arduino blinken lässt und alle Motoren auf 0 setzt und die Bremse setzt (letzteres ist jetzt für den ersten versuchsaufbau irrelevant, aber wenn da mal eine waffe dran hängen sollte sicher nicht schlecht, wenn diese direkt abgebremst wird und nicht frei auslaufen muss. wenn der ESC das schon unterstützt kann man das ja nutzen ).

Die LED sieht man dann im verbauten Roboter zwar nicht, aber für den Test sehr gut, damit ich weiß, dass der code auch wirklich das macht, was ich möchte und nicht einfach nur durch einen fehler im code nicht mehr funktioniert.

Da das ganze aber nicht die Wertermittlung unterbricht, prüft er dauerhaft weiter und sobald wieder mindestens 8 der 10 Werte iO sind geht er wieder in betriebsmodus.

Jetzt wieder zurück zur Ansteuerung der Motoren, hier bin ich gerade am überlegen, ob es leichter zu rechnen geht, wenn ich die Eingangssignale auf % werte umrechne (bei arduino gibt es eine Funktion, mit der man eingangswerte auf eine bestimmte range mappen kann. weiß nicht ob das eine Arduino eigene sache ist oder in C auch so einfach funktioniert).

Da bei der Funke der Gas-Kanal seinen mittelwert nicht in der mitte hat sondern für dosiertes gas geben 2/3 vorwärts und 1/3 rückwärts ist, tu ich mich vermutlich leichter, wenn beide kanäle einfach bei 0 ihren mittelpunkt haben und nicht einer bei 127und der andere bei 85. Da kann ich dann auch gleich eine Deadzone einbauen, damit die werte z.B. nur bis 120 und dann wieder erst ab 130 verteilt werden und dazwischen konstant 0 ausgegeben wird.

Sollte dann gehen über den kurzen befehl

map(Gas, 90, 255, 0, 255)    //Eingangswert von Kanal 1 im Bereich 90-255 umverteilt auf 0,255

Ja das klingt schon mal sehr gut, bin sehr gespannt und hab den anderen thread von dir eben auch schon entdeckt. top!