outdoor I

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

[inka]

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:

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:

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

[Rabenauge]

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.

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;
      
    }
    
  }
}

[inka]

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

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

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.

[inka]

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

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

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

[Rabenauge]

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

[Moppi]

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

[Rabenauge]

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.