outdoor I

Zitat:

---

Zitat von Rabenauge

Hm- wo setzt du das Flag wieder auf 0?
Wahrscheinlich liegt dort der Hase im Peffer....

---

wahrscheinlich...

mit dem einsatz von timer(), sekundenaufgaben() und meiner entprellten ping-abfrage

Code:

---

void hindernis_vorh_rechts_entprellt(void)
{
  if (start_ping_rechts == false)


    aktuelle_ping_millis = millis();
  if (aktuelle_ping_millis - vergangene_ping_millis > interval_ping)
  {
    vergangene_ping_millis = aktuelle_ping_millis;
    ping_distanz_rechts();
  }

  if (uS_rechts != NO_ECHO)
  {
    if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 0)
    {
      hindernis_rechts = true;
      mehrfach_zaehler_rechts = 1;
    }
    else if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 1)
    {
      mehrfach_zaehler_rechts = 0;
    }
  }
  else
  {
    if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 1)
    {
      hindernis_rechts = false;
      mehrfach_zaehler_rechts = 0;
    }
    else if (((uS_rechts / US_ROUNDTRIP_CM) <= 25) && mehrfach_zaehler_rechts == 0)
    {
      mehrfach_zaehler_rechts = 1;
    }
  }
}

---

läuft das jetzt:
der roboter fährt vorwärts und misst im sekundenintervall mal links und dann wieder rechts die entfernung. Die stepper laufen noch ein bischen "rauh" aber das ist sicher ein anderes problem...
zu der (meiner) verwendung von der AccelStepper und auch anderen libraries - ich versuche nicht das alles zu verstehen, sondern passe für meine zwecke die beispiele an, in der hoffnung, dass ich es beim nächsten mal immer noch weiss :-) , klappt leider nicht immer...

Insofern mein dank an alle, die sich immer wieder die mühe machen auf meine fragen einzugehen, wobei hinweise auf andere hardware oder software (welche ausser arduino auch immer) wenig bis garnicht hilfreich sind...

und jetzt gehts mit dem servo-sweep weiter :-)

Wenn du dieses Flag in der selben Sekunde zurückstellst, in der die Aufgabe erledigt werden soll, wird die die ganze Sekunde über endlos oft erledigt, ist doch klar.

Der Ablauf sollte so sein:
- der Sekundenzeiger springt auf "erledigeDas"
-die Aufgabe wird erledigt, das Flag auf 1 gesetzt
-der Sekundenzeiger springt auf die nächste Sekunde- und hier wird das Flag wieder auf 0 gestellt, damit es bei der nächsten "erledigeDas"-Sekunde wieder greifen kann.

Du musst bedenken, dass der Timer ...zigmal pro Sekunde aufgerufen wird- wenn er also in der gleichen Sekunde das Flag wieder auf 0 stellt, klappt das nich.

Zitat:

---

Zitat von Rabenauge

Wenn du dieses Flag in der selben Sekunde zurückstellst, in der die Aufgabe erledigt werden soll, wird die die ganze Sekunde über endlos oft erledigt, ist doch klar.
Der Ablauf sollte so sein:
- der Sekundenzeiger springt auf "erledigeDas"
-die Aufgabe wird erledigt, das Flag auf 1 gesetzt
-der Sekundenzeiger springt auf die nächste Sekunde- und hier wird das Flag wieder auf 0 gestellt, damit es bei der nächsten "erledigeDas"-Sekunde wieder greifen kann.

Du musst bedenken, dass der Timer ...zigmal pro Sekunde aufgerufen wird- wenn er also in der gleichen Sekunde das Flag wieder auf 0 stellt, klappt das nich.

---

so ganz genau weiss ich ja wirklich nicht (beim weiterschreiben habe ich begriffen was da abläuft) warum das jetzt funktioniert :-), es tut's aber - und - ich hab ja für jedes ereignis was über die sekundenaufgaben läuft ja ein eigenes flag...

Mit dem flag alleine hat es ja vorher schon funktioniert, allerdings mit dem nachteil des 100fachen aufrufs und auch des 100fachen drucks des wertes. Das ist nun mit der entprellten ping variante weg...

Ich hab jetzt die ersten versuche mit dem servo-sweep hinter mir. Das hier:

Code:

---

void servo_sweep (void)
{
  gemacht_servo_sweep_flag = 1;
 
  for (pos = 0; pos < 100; pos += 1)
  {
    myservo.write(pos);
    delay(50);
  }
  for (pos = 100; pos >= 0; pos -= 1)
  {
    myservo.write(pos);
    delay(50);
  }
}

---

funktioniert natürlich nicht, das blockiert die stepper. Aber das hier:

Code:

---

myservo.write(30);

---

funktioniert schon, und auch mit dem gesetzten flag für den sweep. Möglichrweise wird der sweep-task ja auch 100x schnell hintereinander aufgerufen, das macht aber nix, weil ja der servo schon in der position ist, bzw. dorthin unterwegs...

Ich denke ich könnte auch mehrere solche timer benutzen, oder? z.b. mit unterschiedlichen intervallen...

Würde gehen.
Aber eigentlich reicht einer-als "Tick" nimmst du halt die kürzesten Intervalle, die du brauchst.
Und die zählst du einfach hoch, um auf längere zu kommen....
Das hier ist der Timer vom XP2- der tickt jede Sekunde, zählt die aber auch hoch, so dass ich Intervalle von bis zu 20 Sekunden habe.
So hab ich einmal den Sekunden-Takt (tick, tack, tick, tack) , aber eben auch nen 20-Sekunden-Takt (den man auch noch unterteilen könnte, wenn man will).
mit intervallTimer=500 könnte man den auch jede halbe Sekunde ticken lassen, ganz wie man will.
Du musst einfach nur den "kleinsten gemeinsamen Nenner" finden, und den dann als Basis benutzen.

Code:

---

void timer()  // ******************************** Bord-Schaltuhr ****************************************               
{
  unsigned long aktuelleMillis = millis();  // Millisekunden auf den aktuellen Wert stellen

  if (aktuelleMillis - vorherigeMillis >= intervallTimer) // immer wenn 1000 Millisekunden um sind
  {
    akkuMessFlag=0;              //alle gemacht-Flags zurücksetzen
    serialFlag=0;
    lichtMessFlag=0;
    vorherigeMillis = aktuelleMillis;
    if(sekundeTick==0)          // Sekunde-Tick wechselt jede Sekunde zwischen 0 und 1
      {
        sekundeTick=1;
     
       
      }
    else
      {
        sekundeTick=0;
      }
    if(timerTick<20)            // Timer-Tick zählt hoch bis 20, und fängt dann wieder bei 0 an
    {
      timerTick++;
    }
    else
    {
      timerTick=0;
     
    }
   
  }
}

---

hallo Rabenauge,
ich wollte mal ausprobieren ob Deine pingversion schneller ist als die mit der ping-lib...

Zitat:

---

Zitat von Rabenauge

Ich benutze keine Bibliothek für das bisschen Ultraschall- das kann man zu Fuss auch machen:

Code:

---

void pingVorne()// ******************** Vorn nach Hindernissen suchen **************************************
{
  delay(100);                            // ggf, alte Echos abklingen lassen, die halbe Zeit reicht auch
  digitalWrite(triggerVorne, LOW);
  delayMicroseconds(2);
  digitalWrite(triggerVorne, HIGH);    //Trigger Impuls 10 µs
  delayMicroseconds(10);
  digitalWrite(triggerVorne, LOW);      //Messung starten
  long laufZeit = pulseIn(echoVorne, HIGH,maxEntfernung); // Echo-Zeit messen, aber nicht zu lange warten
  float messung=laufZeit/ 58.2;        //Laufzeit in cm umrechnen
  entfernungVorne = ((entfernungVorneAlt*0.2)+(messung*0.8)); // Ergebnis glätten
  if(entfernungVorne==0)                // das gibts nicht, also muss die Bahn frei sein
    {
      entfernungVorne=120;
    }
  entfernungVorneAlt=entfernungVorne;
  Serial.print("Vorne: ");
  Serial.print(entfernungVorne);
  Serial.println(" cm");
}

---

---

habe es an meine hardwareverhältnisse angepasst, das sieht dann so aus:

Code:

---

#include "Arduino.h"


#define TRIGGER_PIN_RECHTS  2
#define ECHO_PIN_RECHTS  3
#define MAX_DISTANCE_RECHTS 200 //400

uint16_t distanz_rechts;
uint16_t distanz_rechts_alt;

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

}

void loop()
{
  ping_rechts();

}


void ping_rechts()// ******************** rechts nach hindernissen suchen **************************************
{
  delay(100);                            // ggf, alte Echos abklingen lassen, die halbe Zeit reicht auch
  digitalWrite(TRIGGER_PIN_RECHTS, LOW);
  delayMicroseconds(2);
  digitalWrite(TRIGGER_PIN_RECHTS, HIGH);    //Trigger Impuls 10 µs
  delayMicroseconds(10);
  digitalWrite(TRIGGER_PIN_RECHTS, LOW);      //Messung starten
  long lauf_zeit = pulseIn(ECHO_PIN_RECHTS, HIGH, MAX_DISTANCE_RECHTS); // Echo-Zeit messen, aber nicht zu lange warten
  float messung = lauf_zeit / 58.2;      //Laufzeit in cm umrechnen
  distanz_rechts = ((distanz_rechts_alt * 0.2) + (messung * 0.8)); // Ergebnis glätten
  if (distanz_rechts == 0)            // das gibts nicht, also muss die Bahn frei sein
  {
    distanz_rechts = 120;
  }
  distanz_rechts_alt = distanz_rechts;
  Serial.print("distanz rechts: ");
  Serial.print(distanz_rechts);
  Serial.println(" cm");
}

---

die printausgabe ist: 120 / 24 / 4 und das wiederholt sich....

habe unter den beispielen in der ping-lib etwas durchaus interessantes gefunden. Ein beispiel für drei sensoren, macht einen recht einfachen eindruck:

Code:

---

#include <NewPing.h>

#define SONAR_NUM 3      // Number of sensors.
#define MAX_DISTANCE 200 // Maximum distance (in cm) to ping.

NewPing sonar[SONAR_NUM] = {  // Sensor object array.
  NewPing(2, 3, MAX_DISTANCE), // Each sensor's trigger pin, echo pin, and max distance to ping.
  NewPing(4, 5, MAX_DISTANCE),
  NewPing(8, 9, MAX_DISTANCE)
};

void setup() {
  Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.
}

void loop() {
  for (uint8_t i = 0; i < SONAR_NUM; i++) { // Loop through each sensor and display results.
    delay(50); // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings.
    Serial.print(i);
    Serial.print(" = ");
    Serial.print(sonar[i].ping_cm());
    Serial.print(" cm ");
  }
  Serial.println();
}

---

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.

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

Zitat:

---

Zitat von Moppi

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...

Zitat:

---

Zitat von Rabenauge

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 :-(

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

Zitat:

---

Zitat von Moppi

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?

Zitat:

---

Zitat von Moppi

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...

Zitat:

---

Zitat von Moppi

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 :-)

Zitat:

---

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.

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.

ich habe mich jetzt ein paar tage mit den steppern, dem timing derselben, den unterbrechungen im ablauf durch das pingen nach hindernissen und ähnlichem zeug beschäftigt. Und bin zu dem resultat gekommen, dass ich aus einem vermeintlichen manko nun eine tugend mache :-)

Der roboter war ja von anfang an eher zu einem "gemächlichen" vorgehen und einem eher überlegten agieren konzipiert, nicht zu einem flitzer, bei dem es auf sekundenbruchteile ankommt bevor es kracht. Folgenden ablauf dachte ich mir werde ich anpeilen:

- er schaut ob es in fahrtrichtung ein hindernis gibt, stellt fest wie weit die strecke hindernisfrei ist und fährt in normaler geschwindigkeit los

- nach ca 2/3 der strecke, also ca in 1,5 metern schaltet er runter oder bleibt vielleicht sogar stehen und pingt noch einmal (ohne dass es zu problemen mit den unterbrechungen kommt) und in unterschiedlichen richtungen (evtl. dreht er sich auch um seine achse) und je nach ergebnis bzw. je nach den aufgaben fährt er weiter oder macht anderes...

- das andere kann bestehen aus position über gyro messen, akkuspannung messen und per IR evtl. eine ladestation anpeilen, luftfeuchte messen, temperatur messen usw, usw, usw...

- und je nach aufgabenstellung gehts dann weiter...

Trotz dieses relativ selbständigen vorgehens werde ich auf einen zugriff von aussen nicht verzichten wollen, nun kommt Rabenauges fernbedienung ins spiel...

Schnell fahren wird mit _den_ Antrieben sowieso nix- weder mit den Steppern (denke ich, meine Erfahrung mit den Dingern beschränkt sich bisher allerdings auf 3D-Drucker), aber auf keinen Fall mit solchen Rädern.
Dafür sind die auch gar nicht konzipiert...

Du hast halt zwei Flaschenhälse da: zum einen die ohnehin nicht superschnellen US-Sensoren (geht schon, aber es gibt einfach flotteres), und dann noch das Schwenken- Servos sind für nen Mikrocontroller, so was _richtig_ lahmes.
Insofern halte ich deine geplante Strategie nicht für die schlechteste...wenn es partout nicht geht, die Stepper normal weiterlaufen zu lassen, während andere Dinge getan werden.

Wobei das bestimmt möglich ist: mein Drucker schafft es ja auch, während die Motoren laufen, z.B. das Display zu aktualisieren oder die Temperatur zu überwachen.

Zitat:

---

Zitat von Rabenauge

Schnell fahren wird mit _den_ Antrieben sowieso nix- weder mit den Steppern (denke ich, meine Erfahrung mit den Dingern beschränkt sich bisher allerdings auf 3D-Drucker), aber auf keinen Fall mit solchen Rädern.
Dafür sind die auch gar nicht konzipiert...

---

geschwindigkeit ist auch relativ. in dem video auf youtube sieht man mehr oder weniger deutlich die vier geschwindigkeiten die sich momentan (jetzt vom smartphone) auch während der fahrt bei allen bewegungsarten schalten lassen...

Zitat:

---

Zitat von Rabenauge

Du hast halt zwei Flaschenhälse da: zum einen die ohnehin nicht superschnellen US-Sensoren (geht schon, aber es gibt einfach flotteres), und dann noch das Schwenken- Servos sind für nen Mikrocontroller, so was _richtig_ lahmes.
Insofern halte ich deine geplante Strategie nicht für die schlechteste...wenn es partout nicht geht, die Stepper normal weiterlaufen zu lassen, während andere Dinge getan werden.

---

die servobewegung hat keinerlei einfluss auf den lauf der stepper...

Zitat:

---

Zitat von Rabenauge

Wobei das bestimmt möglich ist: mein Drucker schafft es ja auch, während die Motoren laufen, z.B. das Display zu aktualisieren oder die Temperatur zu überwachen.

---

wenn man an die software käme liesse sich das evtl. auch rausfinden, wobel die NEMA's laufen ja beim drucker sowieso lamgsammer und es wird auch weniger kraft gebraucht, deshalb sind die auch so viel leiser als bei mir...
btw. das druckraumvolumen bei meinem drucker ist 100x100x100mm...

Zitat:

---

Zitat von inka

btw. das druckraumvolumen bei meinem drucker ist 100x100x100mm...

---

Ooook.
Das ist dann ja ein winziges Druckerchen.
Aber für vieles ja auch ausreichend...ich druck eigentlich viel mehr Kleinzeug, was deiner auch könnte, als Sachen, wo ich den grossen (naja-ich hätt gerne mehr) Bauraum wirklich brauche.
Der Prusa Slicer hat übrigens ne Funktion eingebaut, um zu grosse Objekte passend aufteilen zu können.

Und du hast recht: so langsam ist dein Teil ja bei Vollgas gar nicht mal-vermutlich die schnellste Ikea-Box überhaupt?

Dass die Stepper im Drucker langsamer laufen bezweifle ich aber: ich kann durchaus mit 200mm/s fahren. Drucken kann man mit dem Tempo nicht, aber Leerfahrten...und wenn ich da mal deinen Raddurchmesser schätze, und dann den meiner Riemenscheiben dagegen, denke ich, der Drucker wär sogar schneller als dein Roboter.

An die Firmware _kannst_ du doch ran: nimm einfach ne ältere Marlin auseinander- das ist alles schön in einzelne Dateien (allerdings sehr viele...) verpackt, quelloffen.
Kannst du alles schön in die Arduino-IDE laden.
Allerdings-da durchzublicken.....:shock:

Zitat:

---

Zitat von Rabenauge

Das ist dann ja ein winziges Druckerchen. Aber für vieles ja auch ausreichend...ich druck eigentlich viel mehr Kleinzeug, was deiner auch könnte, als Sachen, wo ich den grossen (naja-ich hätt gerne mehr) Bauraum wirklich brauche.

---

das ist er
Anhang 34934 für mich völlig ausreichend, läuft nach anfangsproblemen (die aber mehr mit meinem nicht vorhandenwem wissen als mit dem drucker selbst was zu tun hatten) völlig problem- und anspruchslos...

Zitat:

---

Zitat von Rabenauge

Der Prusa Slicer hat übrigens ne Funktion eingebaut, um zu grosse Objekte passend aufteilen zu können.

---

da wären nähere infos interessant, wie gesagt für grössere sachen... Läuft der slicer unter linux und ohne Prusa drucker?

Zitat:

---

Zitat von Rabenauge

Und du hast recht: so langsam ist dein Teil ja bei Vollgas gar nicht mal-vermutlich die schnellste Ikea-Box überhaupt?

---

sehe ich auch so. Vielleicht sollte ich den thread umbenennen :-)

Aber meine überlegungen darüber, was nach meinen vorstellungen notwendig ist und was nicht, hat auch was mit früher zu tun, als ich noch für geld entwickelt und konstruiert habe:
kennst du die 80/20 regel? Für 80% der funktionalität eines neuen gerätes brauchst du 20% der entwicklungszeit (und der kosten), für die restlichen 20% der funktion die übrigen 80% der ressourcen... und vernünfigertweise verzichtet man dann auf den aufwand...

Zitat:

---

Zitat von Rabenauge

An die Firmware _kannst_ du doch ran: nimm einfach ne ältere Marlin auseinander- das ist alles schön in einzelne Dateien (allerdings sehr viele...) verpackt, quelloffen.
Kannst du alles schön in die Arduino-IDE laden.
Allerdings-da durchzublicken.....:shock:

---

ich glaube das brauche ich nicht, ansonsten siehe oben...

Zitat:

---

Zitat von Rabenauge

Schnell fahren wird mit _den_ Antrieben sowieso nix- weder mit den Steppern (denke ich, meine Erfahrung mit den Dingern beschränkt sich bisher allerdings auf 3D-Drucker), aber auf keinen Fall mit solchen Rädern.
Dafür sind die auch gar nicht konzipiert...

---

Die Stepper im 3D-Drucker machen beispielsweise beim Extruder schon mal 80mm/s, beim Zurückziehen des Filaments. Das entspricht etwa 160U/min, wenn das Ritzel ca. 10mm Durchmesser hat. Korrigiere mich, falls ich falsch liege!
Je nach Kraft und Raddurchmesser sind da theoretisch, mit einem NEMA17 (andere NEMAs hatte ich nie, aber ich denke die werden alle gleich schnell drehen), bis einige Kilometer pro Stunde möglich.


MfG

Ja, es gibt den Prusa Slicer als App-Image auch für Linux.
Läuft super- die aktuelle Version ist mir neulich _einmal_ abgeschmiert, aber die ist auch noch brandneu, und das war auch bei einem Versuch, den man evtl. nicht machen sollte....
Da er noch etliche Features mehr hat (richtig geil ist die variable Schichtdicke!), inzwischen mein absoluter Liebling.

Und klar läuft der mit beliebigen Druckern- du musst halt ggf. nur dein Maschinenprofil erstellen-viele sind aber schon dabei.
Allerdings dein kleiner Exot da- weiss ich nicht....

Übrigens: läuft der mit Mignonzellen ? Wär praktisch, dann könnte man den im Rucksack, beim Wandern dabeihaben, und der kann derweil bisselwas basteln.
Ich find den süss.

Zitat:

---

Zitat von Rabenauge

Und klar läuft der mit beliebigen Druckern- du musst halt ggf. nur dein Maschinenprofil erstellen-viele sind aber schon dabei. Allerdings dein kleiner Exot da- weiss ich nicht....

---

mal schauen, bis jetzt war's ja nicht nötig, ich hatte nix so grosses zu drucken...

Zitat:

---

Zitat von Rabenauge

Übrigens: läuft der mit Mignonzellen ? Wär praktisch, dann könnte man den im Rucksack, beim Wandern dabeihaben, und der kann derweil bisselwas basteln. Ich find den süss.

---

also ich weiss nicht wie lange die paar armen mignozellen so durchhalten würden :p, aber der drucker hat auch kein fest eingebautes netzteil, sondern ein laptopnetzteil (oder sowas) mit 12V, allerdings mit 6A...

btw: durch das setzten und abfragen einer zusätzlich flag-variablen ist es mir nun gelungen, dass er wirklich nur einmal den ping abfeuert und nicht zwei dutzendmal, somit ist die verzögerung kaum noch spürbar....
-----------------------------------------------------------
Jetzt kann ich anfangen mich um die kommunikation zu kümmern, deshalb die frage:
von meinem TT-lok-projekt habe ich noch diesen ESP32, frage an die spezialisten - ist der für sowas (WiFi, BT, I2C abfrage vom gyro und kommunikation mit dem atmega 2560) brauchbar, oder eher nicht? Wenn nein, was bräuchte ich dann?

Wifi und I2C gleichzeitig hatte ich mit nem ESP(kein 32 allerdings, sondern der ältere) auch schonmal gemacht, mit einigen Tricks (zusätzliche Busy-Leitung) hatte das gut funktioniert (war im XPlorer 1).

Aber hast du nicht das RAMPS-Board im Roboter?
Da steckt doch ein Mega 2560 im Unterdeck...der kann, dank endlos vieler Schnittstellen auch ganz problemlos noch ein HC 05/06-BT-Modul mit ansteuern-und ein paar andere Kleinigkeiten.
Wenn du aber den ESP für die Funk-Geschichten nutzen willst-wüsste ich nicht, was dagegen spräche. Aber ich würd die interne Kommunikation vielleicht eher seriell (der Mega hat davon drei) machen, als per I2C (die I2C hat schon so ihre kleinen Tücken).

Wenn schon ein Mega da ist, würde ich vielleicht auch schauen, ob ich damit alles erledigen kann, bloß WiFi hat der nicht. Dafür gibts min. ein WiFi-Shield. Inkl. SD-Karten-Slot. Aber es ist ja ein ESP32 da. Gut, wenn der schon da ist, kann man den benutzen, aber nur für WiFi ist der ja vielleicht etwas überdimensioniert (das wäre so, als würde ich einen 7.5-Tonner einplanen, um meine Einkaufstasche vom REWE nachhause zu fahren) - da würde es auch ein ESP-12E tun oder was noch einfacheres, die könnte man dann ja auch per Schnittstelle, die frei ist, verbinden. Diese "esp8266-ESP-01S-Arduino" Teile sind niedlich und bestimmt dafür ausreichend:

Code:

---

https://www.amazon.de/AZDelivery-esp8266-ESP-01S-Arduino-Raspberry/dp/B01LK83TX0/ref=sr_1_3?dchild=1&keywords=Arduino+arduino+wifi+WiFi+Shield

---

MfG

Zitat:

---

Zitat von Moppi

Wenn schon ein Mega da ist, würde ich vielleicht auch schauen, ob ich damit alles erledigen kann, bloß WiFi hat der nicht. Dafür gibts min. ein WiFi-Shield. Inkl. SD-Karten-Slot. Aber es ist ja ein ESP32 da. Gut, wenn der schon da ist, kann man den benutzen, aber nur für WiFi ist der ja vielleicht etwas überdimensioniert (das wäre so, als würde ich einen 7.5-Tonner einplanen, um meine Einkaufstasche vom REWE nachhause zu fahren) - da würde es auch ein ESP-12E tun oder was noch einfacheres, die könnte man dann ja auch per Schnittstelle, die frei ist, verbinden. Diese "esp8266-ESP-01S-Arduino" Teile sind niedlich und bestimmt dafür ausreichend:

Code:

---

https://www.amazon.de/AZDelivery-esp8266-ESP-01S-Arduino-Raspberry/dp/B01LK83TX0/ref=sr_1_3?dchild=1&keywords=Arduino+arduino+wifi+WiFi+Shield

---

MfG

---

ich habe beide, den ESP32 und den ESP-01S, den habe ich mal gleich zu anfang der IoT ära mal gekauft, allerdings war der umgang damit - zumindest hatte ich damals den eindruck - recht kompliziert. Da der WiFi-fähiger controler aber nicht nur die kommunikation nach aussen machen soll, sondern auch noch anderes (werde diesmal tatsächlich eine aufgabenliste für die beiden controler schreiben :-)) - tendiere ich schon zu dem 7,5-tonner :-)

Zitat:

---

Zitat von Rabenauge

Wifi und I2C gleichzeitig hatte ich mit nem ESP(kein 32 allerdings, sondern der ältere) auch schonmal gemacht, mit einigen Tricks (zusätzliche Busy-Leitung) hatte das gut funktioniert (war im XPlorer 1).

---

ich weiss noch garnicht sicher welcher controle nun was genau erledigen soll, deshalb nun die liste..

Zitat:

---

Zitat von Rabenauge

Aber hast du nicht das RAMPS-Board im Roboter?
Da steckt doch ein Mega 2560 im Unterdeck...der kann, dank endlos vieler Schnittstellen auch ganz problemlos noch ein HC 05/06-BT-Modul mit ansteuern-und ein paar andere Kleinigkeiten.

---

hatt er, an einer hängt schon ein HC05, die "null" ist ja fürs flashen belegt, bleibt noch eine. Der mega 2560 war ja von anfang an drin, als ein fürs fahren zuständiger controler, deshalb hat es ja auch so gut mit der RAMPS idee gepasst :-)

Zitat:

---

Zitat von Rabenauge

Wenn du aber den ESP für die Funk-Geschichten nutzen willst-wüsste ich nicht, was dagegen spräche. Aber ich würd die interne Kommunikation vielleicht eher seriell (der Mega hat davon drei) machen, als per I2C (die I2C hat schon so ihre kleinen Tücken).

---

Ok, dann wird es der ESP32, der für die kommunikation zuständig wird...

Jetzt muss ich aber erstmal die beiden codeteile (fernbedienung und selbständiges fahren) zusammenbinden...

Wenn schon ein ESP32, dann - um Himmels Willen - schau Dir doch bitte, das Ding mit den zwei CPUs an! Ich habe nochmal einen Link gesucht:

Code:

---

https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/esp32-nutzung-beider-cpu-kerne-fuer-eigene-projekte

---

. Dass das Teil einen vernünftigen Einsatz erfährt.

MfG

Zitat:

---

Zitat von Moppi

Wenn schon ein ESP32, dann - um Himmels Willen - schau Dir doch bitte, das Ding mit den zwei CPUs an! Ich habe nochmal einen Link gesucht:

Code:

---

https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/esp32-nutzung-beider-cpu-kerne-fuer-eigene-projekte

---

. Dass das Teil einen vernünftigen Einsatz erfährt MfG

---

hallo Moppi,
es gibt immer gründe für das was man tut :-) , gibt es einen grund dafür links als code zu schicken? Also einfacher macht es's nicht :-( - und selbst wenn ich es rauskopiere und im webbrowser einfüge, komme ich auf eine seite von Ez-delivery, irgendein blog, den ich nicht verstehe...

habe jetzt mal die funktionen auf die beiden controler ein bischen aufgedröselt, ist sicher nicht vollständig, mal der erster stand...

Anhang 34941

gibt es eigentlich eine möglichkeit pdf dokumente / tabellen anders zu posten?

Zitat:

---

gibt es einen grund dafür links als code zu schicken?

---

Ja, weil manche Links von der Forensoftware umgestrickt werden und nicht mehr funktionieren. Daher müsste man jeden Link, nachdem der Beitrag geschrieben ist, ausprobieren und bei Nichtfunktionieren den Beitrag nachträglich editieren.

Und ja, richtig, Du landest auf einem Blog, aus dem hervor geht, dass der ESP32 2 CPUs hat und was man damit machen kann. Einen ähnlichen Link, von einer anderen Seite, hatte ich schon mal hier reingestellt, da ging es um dasselbe Thema, müsste hier im Thread ein paar Seiten zurück stehen.

Zitat:

---

gibt es eigentlich eine möglichkeit pdf dokumente / tabellen anders zu posten?

---

In ein ZIP-File einpacken und anhängen.
Oder Du schreibst Deine Tabelle in einem normalen Texteditor, wo alle Zeichen gleich breit sind, anschließend hier einfügen als Code ;)
Oder Du erstellst mit dem Editor vom Forum eine Tabelle.

MfG

Zitat:

---

Zitat von Moppi

Ja, weil manche Links von der Forensoftware umgestrickt werden und nicht mehr funktionieren. Daher müsste man jeden Link, nachdem der Beitrag geschrieben ist, ausprobieren und bei Nichtfunktionieren den Beitrag nachträglich editieren.

---

man kann es auch unter "erweitert" oder in der "vorschau" testen ob der link funktioniert, also noch vor dem abschicken des beitrages...

Zitat:

---

Zitat von Moppi

Und ja, richtig, Du landest auf einem Blog, aus dem hervor geht, dass der ESP32 2 CPUs hat und was man damit machen kann. Einen ähnlichen Link, von einer anderen Seite, hatte ich schon mal hier reingestellt, da ging es um dasselbe Thema, müsste hier im Thread ein paar Seiten zurück stehen.

---

Ach das meinst Du, ok, ist ja ganz nett, dass der ESP zwei CPU's hat, das würde - zumindest für mich - das ganze aber nicht einfacher machen, eher umgekehrt :-)

Zitat:

---

man kann es auch unter "erweitert" oder in der "vorschau" testen ob der link funktioniert, also noch vor dem abschicken des beitrages...

---

https://www.conrad.de/de/p/draeger-k...t-2201512.html

Also in der Vorschau funktioniert der Link.

Bloß nicht, sobald der Beitrag abgeschickt wurde, wenn er dann erneut vom System ausgegeben wird, wird er verfälscht.
Inka, es wäre toll, wenn Du in Zukunft ausprobierst, was Du behauptest und nicht anderen die Arbeit überläßt, bzw. dass andere sich hinstellen und das Gegenteil beweisen. ;)

Zitat:

---

das ganze aber nicht einfacher machen, eher umgekehrt

---

Dann würde ich Hardware kaufen, die meinen Ansprüchen entspricht. Sich eine Mehrkernhardware zuzulegen und sich nie damit auseinanderzusetzen, die sinnvoll zu nutzen muss man erst mal verstehen lernen.

MfG

seltsam, dass meine links alle funktionieren. wahrscheinlich liegt es daran, dass ich keine conrad-links verschicke. und du kannst ruhig davon ausgehen, dass ich dinge überprüfe bevor ich was behaupte...
btw. den ESP hatte ich schon, wg. Wifi...

Das mit den Conrad-Links ist nichts neues..aber wer kauft da auch, hehe.
Die meisten anderen funktionieren- ich setze ja auch hin und wieder einen....

Hab mir dein Dokument mal angesehen....du willst BT _und_ Wifi nutzen?
Auch, wenn mir nicht ganz klar ist, warum beides- wieso nimmst du dann nicht einfach nen RasPi?
Schon der ZeroW hat beides an Bord...und kostet nun wirklich nicht die Welt (um die 15 Mäuse).

Linux kennst du ja eh schon (sehr hilfreich, wenn man mit RasPi's spielt)...den Mega kannst du trotzdem die Steuerung der Antriebe machen lassen. Das können die besser als ein Pi, zumindest, wenn man den mit Python programmiert.
Ne Kamera könntest du dann auch ganz einfach noch an Bord holen...

Zitat:

---

Zitat von Rabenauge

Hab mir dein Dokument mal angesehen....du willst BT _und_ Wifi nutzen?
Auch, wenn mir nicht ganz klar ist, warum beides- wieso nimmst du dann nicht einfach nen RasPi?
Schon der ZeroW hat beides an Bord...und kostet nun wirklich nicht die Welt (um die 15 Mäuse).

---

Ich bin nicht sicher was und wann sinnvoll ist, wollte mir beide möglichkeiten offen halten...
Und - ich hatte den eindruck, dass es hier von manchem als zu viel des guten gesehen wird wenn man schon den ESP nimmt und den nicht in allen belangen nutzt :-) - und den RasPi? Ein overshoot ohne gleichen, oder? Einen hätte ich ja auch bereits
Anhang 34942
habe ich mir 2012 mal gekauft, nur ein bischen damit rumgespielt, also nicht richtig warm geworden damit. Wahrscheinlich schon total veraltet...

Zitat:

---

Zitat von Rabenauge

Linux kennst du ja eh schon (sehr hilfreich, wenn man mit RasPi's spielt)...den Mega kannst du trotzdem die Steuerung der Antriebe machen lassen. Das können die besser als ein Pi, zumindest, wenn man den mit Python programmiert.

---

Das ist aber kein muss mit python?

Zitat:

---

Zitat von Rabenauge

Ne Kamera könntest du dann auch ganz einfach noch an Bord holen...

---

das ist allerdings ein argument. Also nach ZeroW suchen? Oder doch was anderes?

ob du den zero nimmst oder den alten rpi ist das gleiche, beide haben nur 1 cpu und beide haben wahrscheinlich 512mb, eventeull hat der alte auch nur 256mb, was bei kamera nutzung dann nur noch 128mb sind.

Zitat:

---

Zitat von morob

ob du den zero nimmst oder den alten rpi ist das gleiche, beide haben nur 1 cpu und beide haben wahrscheinlich 512mb, eventeull hat der alte auch nur 256mb, was bei kamera nutzung dann nur noch 128mb sind.

---

ich habe jetzt einen zeroW bestellt :-), es dauer ein paar tage bis der kommt...

Das zusammenfügen der zwei codeteile hat gut funktioniert, muss noch die eingestellten entfernungen ausgiebig testen. Den mittleren vorderen US-sensor wollte ich nach "schräg-unten" ausrichten und so mögliche "negative hindernisse" im boden messen zu können. Bin gespannt ob und wie das funktioniert :-( - gottseidank funktioniert nun die fernbedienung, die ich im notfall als bremse einsetzen kann...

Frage: hat schon jemand versucht von einem HC SR04 einen ping zu schicken und den von einem anderen SR04 zu empfangen?

Hatte ich mal versucht- erfolglos.
Aber sehr viel Mühe hatte ich mir bei dem Experiment auch nicht gegeben...
Bin nicht ganz sicher, aber ich glaube, die Dinger gehn nur dann überhaupt auf Empfang, wenn sie vorher gesendet hatten.

Du willst also Bodenabsätze per Ultraschall finden- da bin ich mal sehr gespannt. Meiner Meinung nach geht das schon-wenn der Sensor steil genug nach unten schaut- ab etwa 45° dürfts aus sein.

Zum RasPi: tu dir bitte nen Gefallen, und benutze _nicht_ das neueste Raspian. Gut möglich, dass es auf den 4ern brauchbar läuft- auf den 3ern eher erbärmlich- und aufm Zero auch.
Jessie läuft sehr gut.

Und nein, natürlich muss man nen Pi nicht mit Python quälen, das geht auch in C- nur dann _richtig_ C- und nicht das, was wir von den Arduinos kennen.
Allerdings: für Python gibt es halt die meisten Bibliotheken...leider.

Ich bin da auch noch hin-und hergerissen: einerseits ist Python genauso ein Blödsinn wie Java: ich brauche nen schnelleren Rechner, damit ich den dann mit nem Bytecode-Interpreter ordentlich ausbremsen kann- andererseits kriegt man in Python schneller was fertig (wobei die Programmiersprache irgendwas von Kindergarten hat, so richtig Spass dran hab ich nicht).

rpi, jessie wird kaum noch unterstützt, stretch ist besser und auch stabil, mit dem rpi4 gebe ich dir recht, wenn möglich nimm einen rpi3

so,
nun habe ich ein paar tage codemässig gebastelt...
Es stellt sich immer deutlicher raus, dass die beiden aktivitäten - fahren und auf hindernisse zu achten - nur unbefriedigend mit einem controler (mega 2560) durchzuführen und nur mit unbefriedigenden qualität von beiden ergebnissen zu schaffen ist. Entweder ist das fahren zu ruckelig und auch zu laut, oder die hindernisserkennung sehr unbefriedigend... Und auch das blinde vorwärtsfahren um anschließend anzuhalten und zu messen ist nicht schön. Man muss auch auf plötzlich auftauchende hindernisse reagieren können...
Würde bedeuten, dass man z.b. für die US-ortung von hindernissen einen nano zusätzlich einsetzt. Platzmässig sicher kein problem :-) , zwei probleme (ich habe mich an die umschreibung herausforderung immer noch nicht so richtig gewöhnt) sehe ich:

- das flashen habe ich bisher mit einer USB verbindung von aussen zum mega gelöst, das wird nun bei zwei, später mit dem zeroW sogar drei controlern und drei USB anschlüssen zu umständlich und zu unübersichtlich. Ich muss ja nicht über USB gehen, ich könnte auch die TX/RX0 pins auch direkt nutzen. Frage hierzu: kann man mit einem drehencoder (nur als beispiel) die TX/RX signale zum jeweils zuständigen controler durchschalten? Oder andere idee?

- die kommunikation zwischen den cotrolern über I2C ist ein neues gebiet für mich (bisher war es nur der mega und das LCD display), aber es ist nicht das erste neue gebiet :-)

früher gab es sowas mal für serielle schnittstellen :D

ich werde das problem anders lösen, ich werde die microcontroller an den raspberry pi anschliessen und dann bei notwendigkeit von da programmieren. ich kommuniziere ja zwischen rpi und mc.

Zitat:

---

Zitat von morob

früher gab es sowas mal für serielle schnittstellen :D

---

genau :-)

Zitat:

---

Zitat von morob

ich werde das problem anders lösen, ich werde die microcontroller an den raspberry pi anschliessen und dann bei notwendigkeit von da programmieren. ich kommuniziere ja zwischen rpi und mc.

---

heisst: ich schreibe den sketch über WLAN von meinem PC aus auf dem raspberry pi (wo die arduino IDE installiert ist) und übertrage es dann auf den jeweiligen mc?