Posts by Wolfgang Glück

Quote from DerMarchegga

Tolles Projekt. Ein R2D2 für den Enkel. Also so einen Opa hätte ich mir auch gewünscht, da hätte ich echt viel Zeit gewonnen weil die Grundlagen dann schneller in meinen Kopf geflossen wären und ich heute
schon tolle Projekte machen könnte

Das Projekt ist wirklich schon sehr weit fortgeschritten und ich bin echt überrascht wie detailliert so ein "Hobby" Projekt sein kann. *Begeisterung*
Schade das die mechanische Hardware so mies ist. Gibt es keine deutschen Hersteller für so ein Roboterchassis ? Da sollte die Qualität dann ebenfalls Begeisterung auslösen ...

Danke für die Veröffentlichung !

Hallo Marchegga
zunächste danke fürs Kompliment.
Ich bin seit dem Projektabbruch nicht mehr in diesem Forum aktiv. Das Forum beherbergt mir zu viele Besserwisser und Nörgler, die zu den gestellten Fragen oft nichts beitragen können.

Natürlich habe ich mich nach Alternativen umgesehen und baue mittlerweile eine Eigenkonstruktion aus einem Alublechgehäuse. Von dem Raupenantrieb bin ich weggegangen und auf Rad umgestiegen, was sofort die Komplexität erhöht. Für den Antrieb verwende ich Standardbauteile aus dem Tuning Programm der 1:10 Modellfahrzeugwelt (Achsschenkel, Differentialgetriebe ...).

Allerdings muss man da nochmals richtig Geld dafür in die Hand nehmen, die Modellbauer verkaufen einem jede Schraube einzeln für 20 EUR.

Viel Spass noch und liebe Grüsse

Ihr könnt meine Projekte und Beiträge ruhig aus dem Forum rausnehmen ich werde das Forum nicht wieder betreten und auch keinen mehr belästigen.

Da fehlt es offenbar auf beiden seiten an Kritikfähigkeit

ok ich mag halt die andere Umgangsart nicht

Übrigens Arduino C hat einen Switch Case

na die while läuft solange im Puffer eine neue Zeile gefunden wird, die Änderung in der Routine ist eh klar, nur damit while was bekommt

jaja optimieren kann man immer, wenns erst mal vom Prinzip her läuft.

Ist so eine Marotte hier im Forum, wenn man das Problem nicht lösen kann mäkelt man am Programmierstil herum. Nichts für Ungut

Es gibt Tricks um den Zyklus zu verkürzen, das musste ich während des Drehens machen um rechtzeitig stoppen zu können bzw. um eine sinnvolle Genauigkeit zu erreichen.

Das rechtzeitige Anhalten mache ich mit einem kleinen Vorhalt von ein paar cm.

Aber zurück zum Thema. Allen Unkenrufen zum Trotz habe ich die Lösung ohne Protokoll:

definition des Parsers

// Commands
// ***********************************************************************************************************************


const int bSize = 25;
int ByteCount;
char Buffer[bSize];             // Serial buffer
char Command[23];               // Arbitrary Value for command size
String CommandString = "";
String CommandStringS = "";     // for mirroring commands


int SerialParser(void)
{
 //  One command per line.
 //  Command Format: "up to 23 letter command + \n"
 //  read up to X chars until EOT - in this case "\n"
 ByteCount = -1;
 ByteCount =  Serial.readBytesUntil('\n', Buffer, bSize);
 if (ByteCount  > 0) strcpy(Command, strtok(Buffer, "\n"));
 memset(Buffer, 0, sizeof(Buffer));   // Clear contents of Buffer
 return ByteCount;
}

Und der Aufruf in der Loop mit Mehrfachauslesen des Interfaces bis es leer ist:

// Get commands from USB interface
    // **************************************************************************************************  
   while (SerialParser() > 0) {
     CommandString = Command;
     CommandStringS = CommandString;
     // It is allowed to change between driving commands directly, no need for a stop command between driving commands
 
     if (CommandString.startsWith("Stop")) {forwardStopCommand = true;
     }
     
     if (CommandString.startsWith("Forward slow")) {
       forwardStopCommand = false; forwardSlowCommand = true; forwardHalfCommand = false; forwardFullCommand = false;
       turnSlow45LeftCommand = false; turnSlow45RightCommand = false;
       turnSlow90LeftCommand = false; turnSlow90RightCommand = false;
       turnSlowLeftToCommand = false; turnSlowRightToCommand = false;
       motorStallLimit = motorStallLimitSlow;


usw.

Und es gibt keine überschriebenen Befehle mehr!!

Naja der Arduino hat einges zu tun da ist die loop halt 400ms lang
Klar sind die Beispiele in den Büchern alle schnell weil ausser dem Beispiel nix läuft!

Wenn du meinen Code anschaust wirst du sehen dass ich genau das mache, was dazu führt dass die Schnittstelle im loop (440ms) 1 x gelesen wird.

Das sind ja alles sehr gut gemeinte Ratschläge, aber keiner kann mir meine Fragen beantworten

recherchieren in der Tiefe des Systems... ohne mich, ich finde es lausig wie das Zeug dokumentiert ist.

In Empfangsrichtung läuft wie gesagt ein ganzer Prozess, der nur die Schnittstelle liest und ich bekomme keinen einzigen Fehler!

Warum ich die Daten nur alle 400ms lese im Arduino, liegt daran dass alle Beispiele das lesen nur im Zyklus machen, ich habe noch kein Beispiel gesehen das auf Timerinterrupt Basis die Schnittstelle liest. Wenn das alle so ohne Zwischenpuffer funktionieren würde könnte ich kein einziges Byte richtig empfangen...

Ich werde mal einen anderen Ansatz versuchen:

- Ich weiss wieviele Daten in 400ms auflaufen können, das sind maximal 4 konkurrierende Befehle macht maximal 100Byte
- Ich übertrage mit 38200 Baud
- Die Kommandos werden falls welche vorhanden sind nach jedem empfangenen Satz in Melderichtung einzeln runtergeschickt (\n als Trennzeichen)
- Ich werde im Arduino die Befehlsschnittstelle mehrfach auslesen (bis \n), bis sie leer ist
- Ich werde nun versuchen rauszufinden wo auf dem Arduino der Puffer versteckt ist und wie gross der ist.

Ein handshake oder acknowledge würde die Befehle ja weiter verzögern bis hin zu einem Befehl pro Zyklus, das ist auch nicht zielführend

ich weiss sehr gut was ein Protokoll ist und was es leistet. Habe früher mal mit Fernwirktechnik zu tun gehabt. Nur für meinen Anwendungsfall ist das oversized. Ich will ja nicht einen kontinuierlichen Datenstrom steuern...

Hallo Andreas, ich mache gerne was nötig ist.

Die Dokumentation von serial ist eher nicht so geeignet mir zu sagen was nötig ist.

In der anderen Richtung habe ich einen Prozess, der nur liest, also da funktioniert alles ohne Protokoll.

Ich versuche mir vorzustellen was da auf der Strecke passiert:
- PC sendet einen Befehl der 18 Zeichen lang ist
Wenn nun nichts weiter gesendet wird landen diese 18 Bytes wo? ich meine solange der Empfänger nicht liest

- Ich kann ja zeigen, dass einzeln gesendete Sequenzen bis \n richtig ankommen. Also kann das Problem nicht innerhalb einer Bytesequenz liegen.

- meine Frage zielt auf den nicht dokumentierten Teil. wo sind die Bytes während des Sendens solange das Lesen noch nicht aktiv ist? in einem Puffer auf PC Seite?
- was passiert wenn der PC die zweite Sequenz hinterherschickt? wird die erste auf PC Seite schon überschrieben? das kann man dann nur über ein Protokoll lösen , soweit einverstanden

Hallo zusammen

ich habe eine Routine für das lesen der Kommandos aus der USB Schnittstelle. Die Schnittstelle bekommt die Daten vom PC bzw. Raspberry.

z.B:

"Forward slow: 1 \n"

Die Zykluszeit des Arduino beträgt ca. 400ms. Der PC kann die Kommandos schneller anliefern z.B. 2 oder 3 Kommandos innerhalb der Zykluszeit des Arduino.

Werden die Daten im Arduino (Betriebssystem) gepuffert, wie gross ist dieser Puffer?
Es kommt vor dass ich im Arduino überschriebene Kommandos sehe (hab sie zum PC gespiegelt)

ich rufe die Routine 1x im Zyklus des Arduino auf. Solange die Kommandos einzeln kommen ist alles richtig.

void SerialParser(void)
{
 //  One command per line.
 //  Command Format: "up to 18 Letter command <\n>"
 //  count will  be below Zero on a timeout.
 //  read up to X chars until EOT - in this case "\n"
 ByteCount = -1;
 ByteCount =  Serial.readBytesUntil('\n', Buffer, bSize);
 if (ByteCount  > 0) strcpy(Command, strtok(Buffer, "\n"));
 memset(Buffer, 0, sizeof(Buffer));   // Clear contents of Buffer
 //Serial.flush();
}

SerialParser();
   if (ByteCount  > 0) {
     CommandString = Command;
     .....

[font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

• ich werde das Projekt in dieser Form abbrechen, siehe Statement am Anfang des Projektes
• Der Bau des Prototyps hat wertvolle Erkenntnisse geliefert und die erarbeitete Lösung ist beachtlich.
• Möglicherweise versuche ich auf Basis neuer Hardware einen neuen Ansatz

So hier noch eine verbesserte Version

Ein alter Wert wird im Schieberegister behalten und zwei neue dazugelesen (Gewichtung der neuen Werte).
Damit erreiche ich zumindest eine Verteilung +- 6cm bei ca. 30 Werten.

// Front
                                                                         // *****
   for (j = 0; j < 2; j++){                                              // 2 measures per cycle        
     digitalWrite(distanceFrontTrig, LOW);                               
     delayMicroseconds(20);                                              
     digitalWrite(distanceFrontTrig, HIGH);
     delayMicroseconds(10);
     digitalWrite(distanceFrontTrig, LOW);
     distanceFrontPulseTime = pulseIn(distanceFrontEcho, HIGH, 47200);   // Range limited to 2 x 400cm (timeout delivers 0)
     if (distanceFrontPulseTime > 60) {                                  // filter for timeout
       distanceFrontCm = distanceFrontPulseTime / 59;                    // 340m/s = 29.4 us/cm for two ways
       
       for (i = 3; i > 0; i --){
         distanceFrontReg[i] = distanceFrontReg[i-1];                    // shift register one step right
       }
       distanceFrontReg[0] = distanceFrontCm;                            // put new value to register


     }
   }
   
   distanceFrontCm = 0;
   for (i= 0; i < 3; i ++){
     distanceFrontCm = distanceFrontCm + distanceFrontReg[i];
   }
   distanceFrontCm = int(distanceFrontCm/3);                             // mean value from last 3 valid values

ich versuchs nochmal auf diesem Weg:

Drei Werte lesen und nur übernehmen wenn sie gültig sind (nicht out of range), davon dann den Mittelwert bilden.

Da ich den Wert nur für die Erkennung eines Hindernisses verwende könnte das reichen.

Ich habe auch herausgefunden, dass die Fehlerquote (out of range) mt den eingestellten Werten 20/10 us am tiefsten ist (ca. 20%)

digitalWrite(distanceFrontTrig, LOW);                               // Front
   delayMicroseconds(20);                                               // *****
   digitalWrite(distanceFrontTrig, HIGH);
   delayMicroseconds(10);
   digitalWrite(distanceFrontTrig, LOW);
   distanceFrontPulseTime = pulseIn(distanceFrontEcho, HIGH, 23600);   // Range limited to 400cm (timeout delivers 0)
   if (distanceFrontPulseTime > 60) {                                  // filter for timeout
     distanceFrontCm = distanceFrontPulseTime / 59;                    // 340m/s = 29.4 us/cm for two ways
     
     for (i = 3; i > 0; i --){
       distanceFrontReg[i] = distanceFrontReg[i-1];                    // shift register
     }
     distanceFrontReg[0] = distanceFrontCm;                            // put new value to register
     distanceFrontCm = 0;
     for (i= 0; i < 3; i ++){
       distanceFrontCm = distanceFrontCm + distanceFrontReg[i];
     }
     distanceFrontCm = int(distanceFrontCm/3);                         // mean value from last 3 valid values
   }
   distanceFrontObstruction = (distanceFrontCm < distanceFrontLimit);  // Obstruction detected front side

interessant, ich bin schon etwas im Zweifel ob ich die richtige Hardware verwendet habe.

Das Rover5 Chassis kann nicht geradeaus fahren ich muss in den beiden PWM Ansteuerungen 30% Differenz einstellen damit der Roboter geradeaus fährt. Dadurch ist der Antrieb einseitig (rechts wird mitgezogen) und die Odometriedaten sind mit einem Fehler beaufschlagt.
Das Chassis hatte eine Differenz zwischen dem linken und rechten encoder...
Die Entfernungsmessung ist unzulänglich mit US-015

Bin kurz davor das Projekt als gescheitert hinzuschmeissen

[font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]WENGLOR CP35MHT80 ist ja nicht ganz billig und für einen Roboter etwas gross[/font]

Die Logik erschliesst sich mir nun nicht, raten kann ich auch selber, es geht um Wissen.

so wie ich die Spezifikation von PulseIn verstehe ist sie ebenfalls interruptgesteuert. d.h. das Programm wird angehalten bis der Impuls von high auf low geht bzw. bis timeout.
In meinem Fall würde das bedeuten der Impuls bleibt auf high und der timeout schlägt zu.

Insofern sollte ein anderer Interrupt nicht stören, höchstens das Zeitverhalten geringfügig verändern, was bei der Encoder routine kaum der Fall sein wird, da die Befehlsfolgen minimal sind.

Was stören kann, ist das Unterdrücken der Interrupts (cli(), sei() während der Ausführung der IRS der Encoder. damit könnte ein anderer Interrupt verloren gehen, wenn ich das richtig interpretiere.

int16_t QuadratureEncoderReadRt( void ) // read single step encoders
{
 int16_t val;
 cli();
 val = encDeltaRt;
 encDeltaRt = 0;
 sei();
 return val; // counts since last call
}

Naja, so simpel war meine Frage natürlich nicht gemeint

Der US Sensoren hat ein Timeout von 23ms eingestellt (Begrenzung des Messbereiches auf 400 cm)

Klar kann ich die Interrupts verhindern, das hat natürlich Folgen, ich verliere Interrupts für das Abtasten der Encoder, was im 1 ms Zyklus passiert. (Die Pulsänge der Encoder beträgt etwa 2ms)

Die Frage ist ob diese Interrupts überhaupt stören können?
Wenn ja, muss ich das Lesen der US Sensoren evtl auch per Interrupt tun.

Quote from ChrisvA

Hallo Wolfgang,
mal ganz objektiv betrachtet mir folgende mögliche Ursachen dazu ein:

• Der Sensor ist "falsch", d.h. die Daten kommen vom Sensor schon falsch (in deinem Fall gar nicht)
  Die Ursache kann dabei entwerder sein, dass der Sensor nicht startet, oder er tatsächlich nichts erkennt (Zu klein, Absorption).

• Der Arduino ist "falsch", das würde bedeuten, dass der Arduino entweder den Start nicht richtig sendet, oder er die Daten des Sensors nicht richtig erkennt
  Die Gründe dafür können z.B. Störungen sein (Stichwort EMV), kurze Einbrüche der Spannungsversorgung, einen zu niedrigen Pegel des Sensors Wie verhält sich die PulsIn Funktion eigentlich, wenn der Pin bereits als HIGH beim Aufruf der Funktion erkannt wird? Dieser Fall kann auftreten, wenn der Arduino "zu langsam" ist.

Hast du ein (digitales) Oszilloskop? Falls ja könntest du dir die Signale vom Sensor mal live anschauen. Wenn der Wert tatsächlich ab und zu sehr oft hintereinander falsch gelesen wird, sollte das Problem zu erkennen sein. (Bei einem digitalen Oszilloskop hilft dir vllt. auch der externe Trigger, den du im Fehlerfall vom Arduino aus triggern kannst (Datenblatt für Spannungen anschauen!!))

Gruß
Chris

Display More

Hi Chris
Die Stromversorgung des Arduino ist ein NiMH Akku mit 10'000 mAh (8x 1.2 V Typ D) , ich würde mal Spanungseinbrüche ausschliessen.

Analysewerkzeuge darauf ansetzen ist eher mühsam bei zyklischen Ereignissen mit sporadischem Effekt.

Die Sequenz im Arduino wird möglicherweise durch die ISR der Encoder unterbrochen.

ISR( TIMER2_COMPA_vect )
{
 int16_t val, diff;


 val = 0;
 if ( LT_PHASE_A )
   val = 3;
 if ( LT_PHASE_B )
   val ^= 1; // convert gray to binary
 diff = lastLt - val; // difference last - new
 if ( diff & 1 ) { // bit 0 = value (1)
   lastLt = val; // store new as next last
   encDeltaLt += (diff & 2) - 1; // bit 1 = direction (+/-)
 }


 val = 0;
 if ( RT_PHASE_A )
   val = 3;
 if ( RT_PHASE_B )
   val ^= 1; // convert gray to binary
 diff = lastRt - val; // difference last - new
 if ( diff & 1 ) { // bit 0 = value (1)
   lastRt = val; // store new as next last
   encDeltaRt += (diff & 2) - 1; // bit 1 = direction (+/-)
 }
 return;
}


void QuadratureEncoderInit(void)
{
 int16_t val;
 cli();
 TIMSK2 |= (1 << OCIE2A);
 val = 0;
 if (LT_PHASE_A)
   val = 3;
 if (LT_PHASE_B)
   val ^= 1;
 lastLt = val;
 encDeltaLt = 0;


 val = 0;
 if (RT_PHASE_A)
   val = 3;
 if (RT_PHASE_B)
   val ^= 1;
 lastRt = val;
 encDeltaRt = 0;


 encLt = 0;
 encRt = 0;
 sei();
 return;
}


int16_t QuadratureEncoderReadLt( void ) // read single step encoders (works correct)
{
 int16_t val;
 cli();
 val = encDeltaLt;
 encDeltaLt = 0;
 sei();
 return val; // counts since last call
}


int16_t QuadratureEncoderReadRt( void ) // read single step encoders
{
 int16_t val;
 cli();
 val = encDeltaRt;
 encDeltaRt = 0;
 sei();
 return val; // counts since last call
}

Kann man die Sensor Sequenz schützen vor dieser Unterbrechung?

Hallo zusammen

ich habe folgende Sequenz im Arduino zum auslesen des Sensors programmiert:

digitalWrite(distanceFrontTrig, LOW);                               // Front
    delayMicroseconds(5);                                                   // *****
   digitalWrite(distanceFrontTrig, HIGH);
   delayMicroseconds(10);
   digitalWrite(distanceFrontTrig, LOW);
   distanceFrontPulseTime = pulseIn(distanceFrontEcho, HIGH, 23200);   // Range limited to 400cm
   if (distanceFrontPulseTime > 60) {                                  // disturbance filter
     distanceFrontCm = distanceFrontPulseTime / 29 / 2;
   }
   else {
     distanceFrontCm = 400;                                            // out of range
   }
   distanceFrontObstruction = (distanceFrontCm < distanceFrontLimit);  // Obstruction detected front side

Die Versuchsanordung besteht aus dem Roboter mit dem Sensor und eine Schachtel im Abstand 25cm vor dem Roboter.

Wenn ich die übertragenen Werte mit der Arduino Entwicklungsumgebung anschaue sehe ich in der Reihe

viele richtige Werte mit 24 und 25 cm
eingestreut der Wert 400cm (timeout) einmalig oder mehrmals hintereinander

Ich kann mich also nicht auf die Messung verlassen!

Mach ich was falsch oder sind die Sensoren nicht verlässlich?

Der Arduino läuft mit einem Zyklus von ca. 400 ms

[font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]Ein neuer Projektstand wurde veröffentlicht.[/font]

• Die Deviation für die Kompassverwendung wurde pro Baumkante (edge) implementiert
  
• Das Fahrprogramm wurde mit minimaler Funktion, ohne Korrekturen, implementiert
  
• Der Roboter fährt nun selbständig von einem gewählten Positionspunkt zu einem Zielpunkt
  
• Leider ist die Mechanik des Chassis so ungenau dass ich mir weitere Schritte für die Stabilisierung der Geradeausfahrt überlegen muss

Quote from georg-Lu_1963-1

Hallo,
weil Du in Deinem code eine Mischung von prozedurale und objektorientierte programmierung verwendest.

Die (sub) Funktion <code>play_next(*args):</code> der <code>Run(self, MQueue, AQueue, CQueue, CommandList):</code> Funktion
macht es noch komplizierter.
Arbeite (füge die Objekte der _init_ Funktion ein ) mit Instanzen, dann wird es viell, viell leichter auf die variablen zuzugreifen.

Gruß
Georg

Ps.
noisefloor

bedeutet -> static deklaration ... iast zwar leichter Weg, funzt nicht immer .... wie auch ist ABER!
mit Vorsicht zu genießen.

Aber sehr gute Vorschlag.

Display More

habs mal umgebaut und so fub ktioniert es! (na so viel viel einfacher ist das auch nicht...

from Robot_Toolbox.Audio import *
import pyglet




class ProcessAudio:
   def __init__(self):
       self.amplifier = False


   def __str__(self):
       nachricht = "Audio process"
       return nachricht


   def Run(self, MQueue, AQueue, CQueue, CommandList):


       def play_next(*args):
           if not AQueue.empty():
               # switch on amplifier
               if not self.amplifier:
                   CQueue.put(CommandList.sendCommandByNumber(13, "1"))
                   self.amplifier = True


               # get order from AQueue
               Audio = AQueue.get()