IR-bake

**Dirk** · 28.01.2014, 17:49

Hi inka,

...könnte die abfrage so aussehen -- if ((t==10) && (tg<520)) --? Ich werde sicher auch noch die passenden stellen für das speichern (und rücksetzen) der zwei variablen t1 und t2 finden, bisher klappte das nicht so ganz

Ich verstehe leider nicht so ganz, was du im Detail machen willst.

Ein Ablaufschema zum Finden der Bake könnte ja so aussehen:
1. Geht mein Akku zur Neige oder habe ich nichts mehr zu tun?
2. Nein: Meine Aufgabe erledigen oder herumstehen, weiter bei 1.
3. Ja: Zur Ladestation fahren:
4. Auf der Stelle so lange drehen, bis die Bake maximal zu empfangen ist.
5. Geradeaus fahren.
6. Bake erreicht?
7. Ja: Weiter bei 13.
8. Hindernis erkannt?
9. Ja: Ausweichen, dann weiter bei 4.
10. Signal weiter gut zu empfangen?
11. Ja: Weiter bei 5.
12. Nein: Weiter bei 4.
-------------------------------------------
13. Ladestation erreicht, Akku laden!
14. Akku voll geladen?
15. Ja: Losfahren und weiter bei 1.
16. Weiter bei 14.
-------------------------------------------

Mit weniger als das wird es nicht gehen...

ich habe mir folgendes im terminal ausgeben lassen, werde daraus aber nicht schlau:

In der Hauptschleife (Suchen der Ladestation) würde ich das machen:
1. task_IR-Empfang -> Einlesen der IR-Empfängerwerte z.B. alle 50ms per Stopwatch. Die Task gibt in einer Variablen z.B. eine 1 aus, wenn die Bake (z.B. mehr als 3x hintereinander) empfangen wird und 0, wenn nicht. In dieser Task keine Ausgaben ans Terminal oder sonstwo, keine Pausen. Die Task ist z.B. eine eigene Funktion, die in der Hauptschleife aufgerufen wird.
2. task_FahreZurLadestation -> Sucht nach der IR-Quelle und steuert dahin. Braucht intern Regeln, die sich nach o.g. Schema richten, und natürlich die permanenten Infos: IR sichtbar oder nicht (aus der task_IR-Empfang), Hindernis erkannt (ACS o.ä.), Ladestation erreicht, Akkustand.
3. task_Ladung -> Akku wird geladen, Ende erkannt. Braucht permanente Info: Akkustand.
Alle Tasks arbeiten autonom (jede z.B. mit eigener/eigenen Stopwatch(es) und teils abhängig von Infos der anderen 2 Tasks:
- task_IR-Empfang läuft immer
- task_FahreZurLadestation läuft nur, wenn task_Ladung gerade nicht läuft und umgekehrt
- Weitere Tasks können gebraucht werden für das hier:
-- Anzeige von Daten (z.B. zum Debuggen). Immer auch mit Stopwatch (0,5 oder 1s, schneller kann man eh nicht lesen)
-- Eigentliche Aufgabe des autonomen Roboters (wenn er nicht gerade zur Ladung muss oder lädt)
-- ...

**inka** · 28.01.2014, 19:30

hi Dirk,
danke für Deine ausführliche antwort...

ich habe wahrscheinlich, nein, sogar ziemlich sicher eine andere herangehensweise an die aufgabe, die ich mir hier gestellt habe, als ein erfahrener programmierer oder elektroniker - beides bin ich auch nicht, auch wenn ich schon einiges gelernt habe... leider geht das viel zu langsam...

Zitat von Dirk

Ich verstehe leider nicht so ganz, was du im Detail machen willst.

meine induktive ladestation besteht aus drei komplexen:

- ladestation - funktioniert soweit...

- ir-bake - an sich funktioniert sie auch...

- das zusammenspiel beim finden der ladestation mit hilfe des IR-empfängers am RP6 - fdunktioniert nicht...

ich kann jetzt einen ablaufplan erstellen wie Du es in Deinem post fantastisch gemacht hast - danke - so in groben zügen hatte ich es mir auch schon skizziert...
Nach Deiner erklärung weis ich (nein, ich ahne es nur) was ein Task ist - ich würde mich aber hier lächerlich machen, wenn ich ernsthaft über "Tasks" und ähnliches reden würde...
Es hilft mir nicht weiter mich mit dem großen plan (den ich ja im prinzip hab!) zu beschäftigen, wenn mir das handwerkszeug fehlt um eine funktionierende verschachtelte if-abfragen-schleife zu erstellen. Beispielsweise move- und rotate- funktion, in abhängigkeit von IR-empfang und abgelaufener zeit, ohne acs, accustand, hindernisse und ähnliches, in der skizzenhaft klar wird, ob meine ir-bake so bleiben kann, oder eben nicht. Zu diese erkenntnis muss ich ab zu mal auch ein paar sachen auf dem terminal ausgeben - das sind alles nur versuche die dinge "im kleinen" zu verstehen. Mit den worten eines feinwerktechnikers - ich kann kein flugzeug bauen, wenn ich von aerodynamik keine ahnung habe...

Und wenn ich ansatzweise weiss, dass die drei komponenten, die ich oben genannt habe auch funktionieren und zusammenspielen, können wir uns gerne über Tasks unterhalten

**Dirk** · 28.01.2014, 20:13

Hi,

Es hilft mir nicht weiter mich mit dem großen plan (den ich ja im prinzip hab!) zu beschäftigen, wenn mir das handwerkszeug fehlt um eine funktionierende verschachtelte if-abfragen-schleife zu erstellen. Beispielsweise move- und rotate- funktion, in abhängigkeit von IR-empfang und abgelaufener zeit,...

Ich denke, es geht vielleicht nicht nur ums Handwerk.

Erklär doch mal (als "Ablaufschema" oder Wenn-Dann-Abfolge), was du in der "verschachtelten if-abfragen-schleife" machen willst! Wenn (auch) ich die Logik verstehe, dann kommt die Umsetzung im 2. Schritt schon ...

... irgendwie ...

... oder ...

**inka** · 03.02.2014, 17:26

hi Thorben,

ich bin da unsicher:
gerade an der stelle hatte ich glaube ich schon alle variationen getestet. Nur break, nur stop, break/stop, stop/break. Die variante break/stop schien mir noch die "erfolgreichste" zu sein - zumindest manchmal passierte beides - er veließ die schleife UND die motoren blieben stehen.

Ich glaube dass es etwas mit der dauer der betätigung der bumper zu tun hat, beim kurzen antippen dreht sich der RP6 anschließend im kreis, bei einer längeren betätigung bleibt er eher stehen...

- - - Aktualisiert - - -

ich hab jetzt die reihenfolge noch einmal geändert, zuerst stop(); und dann break;

so lange er nach rechts dreht, bleibt er beim betätigen des bumpers stehen

wenn er geradeaus fährt, fängt er nach der betätigung des bumpers sich nach rechts zu drehen, mal schneller, mal langsam, er misst nicht dabei, erst wenn ich den button3 betätige, also quasi den case3: noch einmal auslöse, fängt er auch an zu messen und fährt dann (nach empfang) geradeaus wieder richtung bake. Wo im code passiert das? verstehe ich nicht...

**Thorben W** · 03.02.2014, 17:37

Könnte es sein das du in else Schleife Reinkommst da dort ja eine Rechtsbewegung ausgeführt wird?

Code:

case 3://
                ...
                            if (temp == 0)
                            {
                               ...

                            }

                            else
                            {
                                setMultiIOLED1(1);
                                setMultiIOLED1(0);
                                rotate(80, RIGHT, 1, false);
                                setStopwatch3(0);
                            }
                            ...

War nur eine Idee da dort ja ein Befehl für rechts gegeben wird.
gruß Thorben

**inka** · 03.02.2014, 17:46

du meinst, er führt den break in der schleife in der er geradeaus fährt aus und rasselt dann in die else-schleife mit der rechtsdrehung rein? Ist es nicht so, dass dieses else nur dann angesprungen wird wenn in der abfrage

Code:

{
                            temp = read_IR_value();

                            if (temp == 0)
                            {
                                ......

eben temp != 0 ist?