AsuroLib V2.8.0rc1 veröffentlicht

Hallo marvin,
das freut mich aber.

Hier noch ein paar Detailverbesserungen die auf noch kürzeren (hex-)Libcode einerseits und weniger #define-Ballast andererseits, abzielen. Und allgemein auf einfacheren Code abzielen. Aber auch unter Berücksichtigung der tiefen Einsichten von Sternthaler -> Danke!
Und ausserdem habe ich noch ein paar klärende Kommentare mehr gestiftet.
Was will man mehr, oder? ;-)

Hat schon mal einer über Exceptions (bzw. Makros dafür) nachgedacht?
Frei nach dem Motto:

Code:

---

try {
                // Fahre 2m gerade aus!
                GoTurn (2000,  0, 150);
} catch(COLLISION) {
                // Aber falls ASURO dabei auf ein Hindernis stößt sofort stoppen!
                MotorSpeed (0, 0);
}

---

Hallo Sternthaler,
ich muß sagen, dass ich immer schlechte Laune bekomme, wenn ich auf den Code (hier test.c) einer State-Transition-Machine (STM) schaue. Das einzige was die Laune bei Deinem STM-Code hebt sind die wirklich ausführlichen und guten Kommentare.

Wie dem auch sei, Dein Programm (und damit der ASURO) läuft erst mal bei mir wie designed.
Mal sehen ob mir was zu "Kombination" einfällt.

Das mit den Switches ist doch empfindlicher (bzgl. Motor an/aus) als ich dachte und ist von mir jetzt etwas sorgfältiger umgesetzt worden. Deshalb der patch3 im Anhang.

Hallo Sternthaler,

hier meine Überlegungen zur "Kombination" (siehe Anhang): Ich habe Deinen, von Dir vorgegebenen Code (V120.zip), ein wenig gemorpht bis er auch mit der Lib 2.8.0 (plus mein patch3) läuft. Du müßtest Deinen (alten) STM-Code darin gut wiedererkennen, oder?

Das Schöne: Jetzt kommt er sogar ohne STM aus. Die (notwendige) Kooperation zwischen den "Prozessen" findet jetzt mittels wait(..) statt. (Stichwort: subsumption)

All Deine Prozesse: PROZESS_Nav_i(), PROZESS_StatusLEDBearbeiten(), etc. und main() benutzen jetzt wait(..). wait(..) wirkt wie MSleep(..), "vergeudet" aber seine Zeit nicht einfach damit zu warten. Sondern übergibt (in der Zwischenzeit) die Kontrolle an Prozesse mit höherer Priorität! Dazu werden Deine Prozesse, ganz zu Beginn, mittels subsumptionInit(..) an wait(..) übergeben.

Damit das extreme HW_MOTOR_DIFF Deines ASURO keine Rolle spielt, habe ich den Code noch um eine PID-Regelung der Motoren erweitert (siehe PROZESS_MotorRegeln).

Hallo Sternthaler,

hier meine Überlegungen zur "Kombination" (siehe Anhang): Ich habe Deinen, von Dir vorgegebenen Code (V120.zip), ein wenig gemorpht bis er auch mit der Lib 2.8.0 (plus mein patch3) läuft. Du müßtest Deinen (alten) STM-Code darin gut wiedererkennen, oder?

Das Schöne: Jetzt kommt er sogar ohne STM aus. Die (notwendige) Kooperation zwischen den "Prozessen" findet jetzt mittels wait(..) statt. (Stichwort: subsumption)

All Deine Prozesse: PROZESS_Nav_i(), PROZESS_StatusLEDBearbeiten(), etc. und main() benutzen jetzt wait(..). wait(..) wirkt wie MSleep(..), "vergeudet" aber seine Zeit nicht einfach damit zu warten. Sondern übergibt (in der Zwischenzeit) die Kontrolle an Prozesse mit höherer Priorität! Dazu werden Deine Prozesse, ganz zu Beginn, mittels subsumptionInit(..) an wait(..) übergeben.

Damit das extreme HW_MOTOR_DIFF Deines ASURO keine Rolle spielt, habe ich den Code noch um eine PID-Regelung der Motoren erweitert (siehe PROZESS_MotorRegeln).

Hallo rossir,

da hast Du dir ja echt viel Mühe gemacht mein Testprogramm umzugestalten. Ich gebe Dir Recht, die main()-Funktion ist nun hübsch lesbar geworden.
Gut, dass Du als Stichwort Subsumption angeführt hast. Ich hatte vor Jahren (Jahrzehnte wohl eher) mal davon gehört. Aber wie es nun so ist, gerät einiges in Vergessenheit.
Deshalb habe ich auch leichte Probleme damit, wie die von Dir geschriebene wait()-Funktion sicherstellen kann, dass auch die 'Prozesse' mit der niedrigen Prio dran kommen.
Wenn ich als 'böser' Nutzer die Funktion immer nur mit wait(0); aufrufe, dann kann es doch passieren, dass die for()-Schleife nicht bis zur letzten eingetragenen Funktion kommt.
Warum lässt Du die Schleife nicht von 0 bis zur Anzahl der eingetragenen Funktionen/Prozesse laufen?
Oder sogar den Start der For-Variablen mit der letzten Prozessnummer + 1 beginnen? (Klar, am Ende wieder zur ersten Funktion.) Dann kommen auf alle Fälle alle Funktionen mindestens einmal dran.
Was habe ich noch alles vergessen zum Thema Subsumption?

Ansonsten ist die Integration in dieser Form sehr gut gelungen.


Zu Deinem Patch-3 habe ich vor allem zur Funktion adc_low.c/ReadADC() eine Frage.
Warum gibst Du dort mit "return adc >> 6;" den Wert aus adcValue[mux] geshiftet zurück?
In asuro.c/IsrStandard() holt Du die maximale ADC-Auflösung mit "sensor = ADCL | (ADCH << 8 );" und schreibst diesen Wert nach adcValue[adc_cnt]. Somit sind ja erst einmal alle Bits vom Wandler vorhanden. Und auch wenn die Genauigkeit in den unteren Bits eventuell nicht so gut ist, sehe ich keinen Grund die 6 untersten Bits dann zu eliminieren.

In asuro.c/Init() schaltest Du die Odometrie-LEDs ein. Macht ja auch Sinn, wenn der ADC gleich gestartet wird. In adc.c/OdometryData() knipst Du die Lampen auch wieder an und holst die interruptermittelten Daten. Was aber, wenn der 'böse' Nutzer dir die Lampen vorher mal ausgeschaltet hat?
Das gleiche ist auch bei der Front-LED.

Also gilt auch in Deiner Interrupt-Lösung, dass die LEDs, auch die Brems-LEDs, für die Nutzung im eigentlichen Programm tabu sind.
Ich habe für die Brems-LEDs den Ansatz, dass man sie in den Zeiten, in denen die Odo-ADCs nicht in Betrieb sind, den 'Wunsch', die Dinger zu nutzen, dazwischen schiebt. Ist aber noch nicht fehlerfrei, deshalb ist der Code im Timer noch auskommentiert.
Aber zumindest könnten sie dann in Deiner Variante für 4 von 6 ADC-Läufen einschaltbar sein.

Die Einführung vom MY_SWITCH_THRESHHOLD-define ist mir suspekt.
In switches.c/PollSwitch() interpretierst Du einen ADC-Wert größer als dieses Threshhold ja als rauschen. So weit ok.
Aber in asuro.c/IsrStandard() kann ich nicht folgen an der Stelle "switched=switched || sensor<(MY_SWITCH_THRESHHOLD<<6);".
Warum schiebst Du den 'großen' Wert von Threshhold noch mal um 6 Bit. Danach ist es so groß, dass sensor doch immer darunter liegt. Oder etwa doch nicht?


So, genug Fragen für heute.
Dieses Subsumption werde ich jedenfalls auf alle Fälle bei Dir für meine nächsten Test-Programme räubern ;-). Sieht einfach wirklich besser aus.

Gruß Sternthaler

P.S.: Einen Regler habe ich für diesen Test bewusst nicht genutzt, da ich hier die Positionsbestimmung anhand von 'krummen' Geraden sehen will.

Hallo Sternthaler,

zu Subsumption
Subsumption&ASURO war schon mal in einem anderen Thread von mir angesprochen worden.
Siehe Subsumption

So wie ich Subsumption im engen (und ASURO-einfachen) Sinne verstehe kommen Prozesse P(j) mit niedriger Prio erst dran wenn alle Prozesse P(i) mit höherer Prio ( hier i<j ) fertig sind bzw. erst mal "los gelassen" haben. Wenn da ein "unkooperativer" Prozess dabei ist, der z.B. in eine Endlosschleife geht, hat P(j) Pech.

Ich kann auch in wait(..) "die Schleife nicht von 0 bis zur Anzahl der eingetragenen Funktionen/Prozesse laufen" lassen weil P(j) welches ja wait(..) aufgerufen hat sonst ein zweites mal dran käme etc. . Deshalb darf ich die Schleife nur von 0 bis i<j laufen lassen oder, wie im Code steht, "currentTask<callingTask".

Würde mich freuen wenn Du Subsumption nutzt. Hat man mal einen mit dem man drüber reden kann ;-).

zu "return adc >> 6"
Frag mich nicht warum, aber ich habe festgestellt, das gilt
(iADC>>6) == pADC
dabei ist iADC das durch interrupt gewonnene Signal und pADC das entsprechende durch pollen gewonnene Signal!!?? Ok, ADC Werte sind nur 10 Bit genau. (Bemerkung: Ich wüßte auch nichts von 10 + 6 ungenauen unteren Bits.) Vielleicht vergesse ich ja irgendwo ein Flag zu setzen? Keine Ahnung! Entweder habe ich falsch hingeguckt oder die Antwort steht irgendwo im ATMEL Manuel. Da könnte ich Hilfe gebrauchen!

zu adc.c/OdometryData()
Das Einschalten der Odometrie-LEDs habe ich so belassen wie ich es in 2.8.0 vorgefunden hatte. Ich bin darüber hinaus aber der Meinung, dass man hier die Rückwärtskompatibilität aufgeben sollte und die Odometrie-LEDs nicht manipulieren sollte. Denn, wer sie irgendwo im seinem Code ausschaltet wird einen Grund dazu haben.

zu MY_SWITCH_THRESHHOLD
In switches.c/PollSwitch() wird (und wurde schon bei der Jan-Grewe-Formel) von Werten zwischen 0 und 1023 ausgegangen. Und bei dem #define von MY_SWITCH_THRESHHOLD denke ich auch im Intervall [0, 1023].
Wegen "... sensor<(MY_SWITCH_THRESHHOLD<<6);" in asuro.c/IsrStandard() siehe meine Bemerkung zu "return adc >> 6" denn sensor ist ein iADC Wert. Die hübschere Alternative: "... (sensor>>6)<MY_SWITCH_THRESHHOLD;" kostet Laufzeit.

Gruß rossir

Hallo rossir,
wollte nur kurz mitteilen, dass ich länger im Forum bin als Du ;-). Somit bist Du produktiver beim Codebasteln :cheesy: .

Oh, dann habe ich das sehr wohl richtig gelesen, dass es auch mal zu vernachlässigten Prozessen kommen könnte. Hmm, hmm, ich glaube, dass mir das nicht gefällt. Oder fehlt mir nur die Erfahrung, dass es eigentlich nicht vorkommen wird, wenn die entsprechenden Prozesse richtig arbeiten? Wir werden wohl weiter zum Thema im Gespräch bleiben.

Deine Antwort zu den Shift-Aktionen muss ich mir noch mal ganz in Ruhe ansehen. Möglicherweise habe ich beim Durchstöbern vom Code etwas übersehen. Denn so richtig leuchtet mir jetzt Deine Erklärung nicht ein.

Den Link zum "Siehe Subsumption" kannte ich noch nicht. Interessant, wie sich die Struktur der AktionsList geändert hat.

Gruß Sternthaler

Hallo Sternthaler,

ok, Du hast gewonnen, Du bist länger im Forum drin als ich ;-).
Eigentlich wollte ich gar nicht lange drin sein. Dauert aber so verdammt lange einen Forum-Beitrag zu schreiben. Bin darüber jedes mal aufs Neue überrascht. Gehts Dir da ähnlich?

Ja, es kann zu "vernachlässigten Prozessen kommen". Aber, auch hier könnte man die Ansätze kombinieren. Wie gefällt Dir das Folgende (nur ca.):

Code:

---

/*----------------------------------------------------------------------
    Daten sammeln
*/
void PROZESS_DatenSammeln(void) {
static int v_status=0;
static long v_pause_bis;

          if (v_taster != T_1) return;
         
      if (v_status == 0)
      {
        v_LED = RED;                    // User sieht rot
        v_pause_bis = Gettime () + 1000; // Pausenzeit nach Taste losgelassen
        //sens.aktiv |= SENS_RAD;          // Rad-Sensoren starten
        md.i [LINKS]  = 0;              // Die ersten N Messungen verwerfen
        v_status++;
      }
     
      if (v_status == 1)
      {
        if (v_pause_bis < Gettime())    // Pausenzeit abwarten
        {
            v_LED = GREEN + BLINK;        // User warnen: Asuro faehrt los
            v_status++;
        }
      }

      if (v_status == 2)
      {
                    /* Motor starten und warten bis der MessDaten-Puffer voll ist */
                    drive (220, 220);  // Geradeaus soll es gehen
                    md.i [LINKS]  = 0;              // Die ersten N Messungen verwerfen
                v_status++;
      }

      if (v_status == 3)
      {
                    PositionBerechnen=1; //PROZESS_PositionBerechnen: Macht nur Sinn, wenn die Messdatenaufnahme laeuft.
                   
        if (md.i [LINKS] == 20)    // Kurve einleiten
        {
            drive (100, 160);
        }
        if (md.i [LINKS] == 30)    // wieder geradeaus
        {
                    drive (220, 220);  // Geradeaus soll es gehen
        }
        if (md.i [LINKS] == 60)    // Kurve einleiten
        {
            drive (250, 140);
        }
        if (md.i [LINKS] == 70)    // wieder geradeaus
        {
                          drive (220, 220);  // Geradeaus soll es gehen
        }
        if (md.i [LINKS] >= MD_RECORD_ANZ - 1)
        {
                    drive (0, 0);            // Motor aus
                    //MotorDir  (BREAK, BREAK);
                    //sens.aktiv &= ~SENS_RAD;      // Rad-Sensoren stoppen
               
                    v_LED = RED + BLINK;          // User ist wieder daran
            v_status = 0;
                    PositionBerechnen=0;
                    v_taster=0;
        }
      }       
}

---

Das ist wahr, "die Struktur der AktionsList" und damit das Subsumption Framework hat sich stark vereinfacht. War viel zu viel Balast für die mit dem ASURO möglichen Programmgrößen.


Gruß rossir

Hallo zusammen,

um die 'lebenswichtige' Frage von rossir zu beantworten: Ja, ich benötige mindestens 3- bis 12-mal so viel Zeit zum Antworten als ich mir vorgestellt hatte. Ist halt wie im echten Projektleben. Die Verschätzung ist anhängig vom 'PI mal Daumen Faktor' und der Stärke des Sonnenwindes.


Hallo rossir,

auch hier hat alleine das betrachten Deiner Coderevision zu einigen Gehirnaktivitäten geführt. Ich bin nicht davon überzeugt, dass diese Mischform Vorteile bringt.
Wenn der Subsumption-Vorgang diesen Prozess 'vernachlässigt', dann bedeutet die Ablaufsteuerung innerhalb dieses Prozesses ja automatisch, dass sie mehrfach aufgerufen werden muss um wieder in den Zustand "v_status = 0" zu kommen. Somit besteht die Möglichkeit, dass sie bei mehrfacher 'Vernachlässigung' viel länger dauern wird als angenommen wird. Das Timing der Funktion gerät damit in den Bereich, in dem es nicht mehr nachvollziehbar wird.

Da ich dies aber aktuell nur als Theoretiker schreibe, werde ich morgen/heute doch wohl den Test am Asuro abbrechen müssen, wie dick eine Staubschicht dein darf um noch Daten hindurch zu IR-en.

Gut, dass Du schreibst "nur ca.". Ich hätte da schon Probleme mit der ersten Ausstiegsbedingung "if (v_taster != T_1) return;". Für mich sieht das aktuell so aus, als ob ich den Taster die ganze Zeit festhalten müsste während der Asuro seine DatenSammelFahrt macht.
Wahrscheinlich reicht ein

Code:

---

if (v_taster != T_1 && v_status == 0) return;

---

um hier den Prozessablauf 'am Leben' zu halten.


So, jetzt muss ich erst einmal weiter im Buch der Zukunft lesen. Ist aktuell von John Scalzi. Der 4.te Band 'Androiden Träume' (http://de.wikipedia.org/wiki/Scalzi). Ich bin nur begeistert. Das letzte Gedruckte mit echtem Begeisterungsfaktor war 'Die Ringweltsaga' von Larry Niven (http://de.wikipedia.org/wiki/Ringwelt).

Gruß
Sternthaler

Hallo zusammen,
dieser thread passt grad für mein Problem, auch wenn länger keiner mehr was geschrieben hat.
Also anfang der Woche hab ich mir nun auch ein asuro zugelegt (jaja, Semesterferien sind laaaange :cheesy: ); daher bin ich in dem Bereich noch ein Anfänger^^. Bisher funktioniert eigentlich alles wunderbar - bis auf dieses leidige problem mit den tastern.

Jedenfalls um auf das eigentliche Problem zurück zu kommen:

Nachdem ich neueren Verionen der Asuro-Libs entdeckt hatte, hab ich mir die neuste (AFSetup_v280rc1) geholt. Wenn man dann die exe-Datei ausführt wird das Programm "Asuro Flash(Alias Eierlegendewollmilchsau) V1.4.6.56" installiert. Wie darf man das jetzt verstehen? Denn unter der lib hab ich mir eigentlich was anderes vorgestellt. Oder beinhaltet dieses Programm die neue lib? Sry für diese wahrscheinlich super-banale Frage, aber bis man sich da mal reinarbeitet isses doch ein längerer weg. :?

Gruß
foerstie