Weg aufzeichnen und Aufzeichnung abspulen

hrhr... ich denke mal, dass mit einem komprimierungsalgorithmus mehr platz verbraucht wird als durch die komprimierten daten gewonnen...

wenn man allerdings versucht befehle aufzunehmen, dann sollte der eeprom doch reichen. man könnte auch 2 bytes für jeden befehl abspeichern (zB ein byte "vorwärts" zweites byte "eine sekunde"), dann sind immer noch 256 befehle speicherbar. damit kann man doch was anfangen. mit 265 befehlen kann der asuro schon recht lange fahren... auf der fernbedienung wäre das dann "nach oben" und "2" nacheinander gedrückt.

um dem problem mit dem rc5-code zu entgehen ist mir nochwas eingefallen: man nehme eine lernfähige fernbedienung (gibts ab 1 euro im ramschladen und bei ebay, das billigste modell reicht), stellt diese auf "lernmodus" und benutzt den transceiver um zB die fernbedienung den buchstaben "A" lernen zu lassen auf die nach-oben-taste. dann müsste die fernbedienung doch auf dieser taste ein "a" senden, oder? der asuro müsste dann den code nicht mehr decodieren, sonden nur ein "A" empfangen. wäre das möglich? oder lernt eine fernbedienung nur rc5-code? im endeffekt kann man doch auch nicht-rc5-konforme fernbedienungen einlesen, oder?

Das mit der Lern-Fernbedienung ist gar keine schlechte Idee, könnte vielleicht funktionieren.

Hallo Leute,
warum wollt ihr unbedingt schon mit einer Fernbedienung anfangen?
Als Idee ist das ganze schon mal unter dem Nikolaus an dieser Stelle angedacht.

Es bleibt aber auch an der Stelle dabei, dass das Problem mit dem Speicherplatz noch nicht 'überdacht' ist.

Hallo Sternthaler,

das mit der Fernbedienung hat meiner Meinung nach einen bestimmten "Spaßfaktor". Man kann den ASURO ohne groß die Bewegungen vorher zu programmieren intuitiv steuern. Und wenn man eine "Repeat" Taste hat, das ganze noch mal abspulen. Wenn man Glück hat, ist die Wirkung des Vorgangs ganz interessant, auch wenn es mit der Positionsgenauigkeit nicht so weit her ist.

Beste Grüße,
stochri

Fernbedienung? Meines Erachtens völlig inakzeptabel. Ein Roboter muss autonom "werkeln". ;-)

Ich finde die Idee auch klasse. Deshalb hier mein Programm:

Code:

---

#include "asuro.h"

#define NORMAL GREEN
#define PLAY YELLOW
#define REC RED

#define MAXSTORE 30
char dataStore[MAXSTORE]={ '9' };
unsigned int timeStore[MAXSTORE];

int main(void) {
        char f=40, s=30, mode=NORMAL, idx=0, data;
        unsigned int time=0;
        long t0;
               
        Init();       
        EncoderInit();
        EncoderStart();
        while(1) {
                t0=Gettime();       
                StatusLED(mode);
                SerRead(&data, 1, time);
                switch(mode) {
                        case PLAY:
                                if(data=='T') {
                                        data=dataStore[idx];
                                        idx++;
                                        time=timeStore[idx];
                                } else {
                                        mode=NORMAL;
                                }
                                break;
                        case REC:
                                timeStore[idx]=Gettime()-t0;
                                dataStore[idx]=data;
                                idx=(idx+1)%MAXSTORE;                       
                }

                switch(data) {
                        case '9': mode=(mode==NORMAL) ? REC : NORMAL; time=0; idx=0; break;                                       
                        case '0': mode=PLAY; time=1; idx=0; break;                                       
                        case '1': Move( 0,        f, 0); break;
                        case '3': Move(-s,        s, 0); break;
                        case '5': Move(-f,        0, 0); break;
                        case '2': Move( f,        f, 0); break;
                        case '6': Move(-f,        -f, 0); break;
                        case 'o': Move( f,        0, 0); break;
                        case 'p': Move( s,        -s, 0); break;
                        case 'u': Move( 0,        -f, 0); break;
                        default:  Move( 0,        0, 0);
                }
        }
}

---

1) Ich habe das Glück eine lernende Fernbedienung zu besitzen, die in der Lage ist RS232 Signale zu lernen. (Sollte aber auch mit ReadRC5() gehen.)

2) SerRead(.., timeout) ist bei mir so umgebaut, dass timeout in ms angeben wird. Kompatible zu Gettime().

3) Der Clou: Move(..) nutzt die Encoder-Odometrie und ist interrupt getrieben ( = läuft im Hintergrund ). Dadurch ist das Ganze sehr wiederholgenau.

An alle Fernbediener:
Ich finde die Idee auch klasse, hatte als Einwand nur, dass man evl. erst mal mit einem 'Lernmode' anfängt, ohne gleich auch die 'Schwierigkeiten' mit einer Fernbedienung zu behandeln.
Das scheint aber wohl kein Problem zu sein.

@rossir
Kannst du mal bitte die Parameter und die Funktion von Move() erklären. Code?

Hi,

Zitat:

---

Zitat von damaltor

hrhr... ich denke mal, dass mit einem komprimierungsalgorithmus mehr platz verbraucht wird als durch die komprimierten daten gewonnen...

---

wenn Du Dich da mal nicht verlachst!

Ich hatte schon mal mit dem GZIPInputStream von Tinyline gearbeitet, dessen .jar-File (Java !) war ganze 6KB groß:
http://www.tinyline.com/utils/index.html

Habe damit sogar auf dem Siemens S55 entzippen können -- wenn man in Java einen Entzipper in 6KB machen kann, dann kann man das in C und/oder Assembler doch wohl mit viel weniger Platz, oder?

Nur so als Beispiel: wenn man einen entzipper in 2KB hinkriegen würde, hätte man in den 5KB abzüglich des eigentlichen Programms richtig viel Platz(abhängig vom Komprimierungsgrad der Daten) ...

Falls sich jemand berufen fühlt, hier die notwendigen Infos zum Programmieren eines Entzippers:
http://de.wikipedia.org/wiki/Gzip

Gerade noch vor dem Absenden gegoogled:
http://en.wikipedia.org/wiki/DEFLATE

Zitat:

---

Zitat von from wikipedia-DEFLATE

... Other possible focuses for a DEFLATE implementation could be super-fast compression speed, or being designed to have a very small executable code such for use in embedded systems. ...

---

Zitat:

---

Fernbedienung? Meines Erachtens völlig inakzeptabel. Ein Roboter muss autonom "werkeln".

---

Aber, aber ... Dogmatismus ist des Kreativen Tod. [-X
Man muss die Ideen aufgreifen, die am Rand des Weges liegen. =P~

@sternthaler
Hier der Code von Move(..). Inspiriert von Travel(..) und Rotate(..).
Allerdings bereitet Move(..) nur vor.
Die einfache encoder-Regelung (auch inspiriert von Travel(..) bzw. Rotate(..)) ist in SIGNAL (SIG_OVERFLOW2) {..} eingehängt, ähnlich wie dies für IsrRC5() in der Lib gemacht wird.

Code:

---

/*  @param leftSpeed left motor speed in ticks per second. positive = forward, negative = backward
 *  @param rightSpeed right motor speed in ticks per second. positive = forward, negative = backward
 *  @param distance [mm].
 *                Stop if sum(leftTicks, rightTicks) > abs(distance).
 *                Run in background if distance<=0.
 *                Forever if distance==0.
 *  @return err in number of summed ticks
 */
int Move(const int leftSpeed_, const int rightSpeed_, int distance_) {
        int tmp;
       
        Ta=0;
        if(t1==0 || Gettime()-t1>1000) {
                t1=Gettime();
                EncoderReset();
        }
        // We want to have at least 3 ticks collected from slowest encoder side and timeslot.
        // Deshalb, suche sinnvolles Zeitintervall
        // Idea:        Ta=1000/(ticks/3)
        tmp= abs( (abs(leftSpeed_)<abs(rightSpeed_)) ? leftSpeed_ : rightSpeed_ );
        tmp= (tmp>0) ? 3*1000/tmp : 10;
        if (tmp<10) tmp=10;        //not to smal
        if (tmp>300) tmp=300;        //not to big

        // Werte für Interruptroutine
        measure=(distance_!=0);
        distance=distance_*6/10;
        leftSpeed=leftSpeed_;
        rightSpeed=rightSpeed_;
        Ta=tmp;

        while(distance>0&&distance_>0&&leftSpeed!=0&&rightSpeed!=0) mSleep(1);
        return distance;
}

---