outdoor I

[Rabenauge]

Hm- wenns funktioniert....ich hatte mal bei anderer Gelegenheit die NewPing probiert, war aber keineswegs von begeistert.
Aber ich weiss nicht mehr genau, was war....

Mein Code ist _nicht_ auf Speed optimert: du kannst z.B. das anfängliche delay noch deutlich runtersetzen (musst du mal rechnen, wie weit die Dinger maximal kommen können, dann kommst du mit der Schallgeschwindigkeit auf den Wert, den du evtl brauchst)- oder du lässt es ganz weg- im Freien wirst du eher keine solchen wilden Echos haben.
Die Ansteuerung muss so-laut Datenblatt.
Man könnte versuchen, den Triger auch kürzer anzusteuern- vielleicht klappts, vieleicht nicht.
Auch die maxDistance kann man an die konkreten Anforderungen anpassen, wenn man die verkürzt, spart man auch Zeit, da pulseIn() blockierend ist (das wartet einfach bis entweder das Timeout abgelaufen ist oder was rein kommt).

Den letzten Rest kann man bei der Umrechnung rausholen, indem man auf die Fliesskomma-Berechnung verzichtet, und das so umbaut, dass die nicht mehr nötig ist.

[Moppi]

Guten Morgen,

welche Abfragezeit wird denn benötigt, wie schnell wird das Ergebnis benötigt, wie sicher soll es sein? Danach sollte sich dann die Sensor-Auswahl richten. So einen US-Wandler kann man nur in bestimmten Intervallen abfragen, nicht unendlich schnell. Beim SRF05 habe ich eine Angabe von min. 50ms im Netz gefunden, als Zeit zwischen den einzelnen Messungen. An anderer Stelle ist die Rede von 65ms.


MfG

[inka]

welche Abfragezeit wird denn benötigt, wie schnell wird das Ergebnis benötigt, wie sicher soll es sein? Danach sollte sich dann die Sensor-Auswahl richten. So einen US-Wandler kann man nur in bestimmten Intervallen abfragen, nicht unendlich schnell. Beim SRF05 habe ich eine Angabe von min. 50ms im Netz gefunden, als Zeit zwischen den einzelnen Messungen. An anderer Stelle ist die Rede von 65ms.

das sind alles fragen mit denen ich mich bis dato nicht beschäftigen musste. Weder bei den gelben DC-getriebemotoren (weil PWM) noch bei den kleineren Schrittmotoren mit ihren ansteuerungsmodulen. Es lief einfach in der standareinstellung, man musste nur einstellen unterhalb welcher entfernung der arduino einschreiten musste...

die 3sensor geschichte von newping verbessert das verhalten bei den NEMA steppern etwas, trotzdem sind aussetzer der Stepper spürbar (und hörbar). Vielleicht muss ich die pulseIn besser "verteilen", die Sensoren zwar mit der 3sensor einstellung aber einzeln abfragen. Mal sehen...

Mein Code ist _nicht_ auf Speed optimert: du kannst z.B. das anfängliche delay noch deutlich runtersetzen (musst du mal rechnen, wie weit die Dinger maximal kommen können, dann kommst du mit der Schallgeschwindigkeit auf den Wert, den du evtl brauchst)- oder du lässt es ganz weg- im Freien wirst du eher keine solchen wilden Echos haben.

das war klar, allerdings hatte ich den eindruck, dass die von mir abgeänderte version gar nicht ging, weil sich die drei werte ständig wiederholt haben, egal wie gross die entfernung des hindernisses zum sensor war

[Moppi]

Mit dem pulseIn() ist es wie mit dem delay(). Das kannst Du auch zu Fuß machen (pulseIn ist einfacher zu handhaben).

Brainstorming (keine Ahnung ob das schon 100% so richtig wäre, bloß wegen der Vorgehensweise):

1. Auf der ECHO-Leitung auf High warten.
2. micros() - Mikrosekunden auslesen.
3. Auf der ECHO-Leitung auf High warten.
4. micros() - Mikrosekunden auslesen.
5. Den ersten vom zweiten Mikros-Wert subtrahieren.

Wenn der Code schnell genug durchläuft (also genügend Durchläufe pro Sekunde schafft) sollten auch diese dann so ermittelten Werte gut genug sein. Voraussetzung ist natürlich, dass keine andere Stelle im Code Hänger verursacht.

Wegen den Steppern nochmal:

Ich will nicht dazu verleiten, andere Hardware einzusetzen. Aber die Steuerung der einzelnen Schritte geschieht doch im Mikrosekundenbereich. Sobald es dort, z.B. über eine halbe Millisekunde (oder weniger), zu Verzögerungen - zwischen den einzelnen Schritten - kommt, merkst Du das u.U., eben daran, dass es nicht gleichmäßig läuft. Deshalb würde ich die Motoren unabhängig steuern.
Wenn ich an einem NANO (z.B.) vier Pins zur Steuerung der Motoren festlege, kann ich mit HIGH oder LOW, auf jedem der Pins, einen Motor aus- oder einschalten. Der NANO muss nur diese vier Leitungen überwachen und würde in loop() einfach nur die Stepper bedienen, damit laufen die dann absolut gleichmäßig. Es würde auch ein 328P in Minimalbeschaltung ausreichen: Quartz und 2 Kondensatoren.

Ob Softwarelösungen per AccelStepper-Lib oder was auch immer da genau so gute Ergebnisse liefern, dazu vermag ich kein Urteil abzugeben, weil ich das noch nicht benutzt habe. Wäre auszuprobieren.
Kommt drauf an, wieviel Software auf den MEGA bzw. den ESP32 zum Laufen kommen soll, wenn da mehrmals irgendwie Interrupts ausgelöst werden, um 3 oder 4 verschiedene Dinge zu steuern, könnten die ISRs sich auch gegenseitig in die Quere kommen. Wenn das Projekt etwas ausladender wird, kommt da sicher mehr als nur 4 Stepper ansteuern und zwei US-Wandler bedienen zusammen. Und zu anderen (Multithreading / Multitasking) hat HaWe auch schon viel geschrieben. Das würde ich mir dann auch mal anschauen.

Muss am Ende jeder selber wissen, wie er es macht.


MfG

[inka]

Mit dem pulseIn() ist es wie mit dem delay(). Das kannst Du auch zu Fuß machen (pulseIn ist einfacher zu handhaben).

pulseIn einfacher zu handeln als delay, oder ist es anders gemeint?

Wegen den Steppern nochmal:

Ich will nicht dazu verleiten, andere Hardware einzusetzen. Aber die Steuerung der einzelnen Schritte geschieht doch im Mikrosekundenbereich. Sobald es dort, z.B. über eine halbe Millisekunde (oder weniger), zu Verzögerungen - zwischen den einzelnen Schritten - kommt, merkst Du das u.U., eben daran, dass es nicht gleichmäßig läuft. Deshalb würde ich die Motoren unabhängig steuern.

wenn - und es würde das wirklich vereinfachen - würde ich den MEGA für die motoren nehmen, schon wegen der gut gelösten aufnahme der vier steppersteuermodule auf dem RAMPS. Und evtl. ergibt sich später ja noch etwas was die Stepper nicht stört und auf dem MEGA laufen könnte...

Kommt drauf an, wieviel Software auf den MEGA bzw. den ESP32 zum Laufen kommen soll, wenn da mehrmals irgendwie Interrupts ausgelöst werden, um 3 oder 4 verschiedene Dinge zu steuern, könnten die ISRs sich auch gegenseitig in die Quere kommen. Wenn das Projekt etwas ausladender wird, kommt da sicher mehr als nur 4 Stepper ansteuern und zwei US-Wandler bedienen zusammen. Und zu anderen (Multithreading / Multitasking) hat HaWe auch schon viel geschrieben. Das würde ich mir dann auch mal anschauen.

und das ergibt sich nach und nach, da sind meine vorstellungen nicht ganz so präzise ausgeprägt...
Manchmal ist auch der weg das ziel

[Moppi]

pulseIn einfacher zu handeln als delay, oder ist es anders gemeint?

pulseIn ist einfacher, als wenn Du das zu Fuß, Schritt für Schritt, selbst erledigst, so ist das gemeint.
Bloß pulseIn blockiert eben.

MfG


PS: von AccellStepper abgesehen. Du kannst natürlich auch selber eine ISR programmieren, die die Logiklevel für die Schritte der 4 Motoren setzt.
Ich hatte als Beispiel für die Rollosteuerung den Timer#1 vom 328P verwendet, um die Uhrzeit fortzuzählen. Kompliziert war das nicht.
Das funktioniert eigentlich gut. Auf dem MEGA2560 müsste so was ja auch funktionieren.

[Rabenauge]

PulseIn läuft so ab:

pulseIn(); // warten ob an dem Pin was passiert, im Normalfall (kein Timeout eingestellt) maximal ne volle Sekunde (wie delay(1000)).
Die Zeit wird kürzer, wenn innerhalb der Sekunde das Echo eintrifft.
Dann ist das Warten beendet.

Aber man _kann_ eben auch ein Timeout angeben- damit kann man die Verzögerung auf das Nötigste beschränken (der Ping braucht nur bis zum Hindernis und zurück).
Das kann man anhand der gewünschten Entfernung problemlos berechnen.

Zu Fuss würd ich es nicht machen, ausser, man kann für den Echo-Eingang nen Interrupt-Pin benutzen. Sonst riskiert man, das Echo zu verpassen, weil der Controller grade was anderes macht.