Odometrie Array-PIC

[sensemann]

hallo.

hat jemand zufällig erfahrungen damit odometriewerte in arrays zu schreiben?

ich hab nämlich das problem dass ich nicht weiß welchen compiler ich verwenden soll.

Ich habe bisher meine PIC's mit MPLAB und dem Compiler CC5X programmiert. allerdings ist beim CC5X bei 256Bit schluss was die Arrays angeht.



zur verdeutlichung:

lichtschranken an den antriebsrädern geben impulse als hardwareinterrupt. diese interrupts erhöhen eine variable i.
dann hatte ich vor, per timerinterrupt von zeit zu zeit i in ein array schreiben zu lassen, so dass ich diese im array abgespeicherten daten später wieder nutzen kann.

oder gibt es bessere wege odometriedaten zu speichern? bin für jeden tip dankbar.

viele grüße.

[sensemann]

gibts denn hier keinen der erfahrungen mit odometrie hat?

leute wie steuert ihr denn eure maschinen an??

[Thoralf]

guck mal dort:
http://www.mikroe.com/de/compilers.htm

der Compiler ist recht gut. Ich mache meine gesamte Arbeit damit. Dazu gehört das Entwicklungssystem easyPIC. Klar, der Preis ist nicht gerade gering.
Kannst du mit den Restriktionen der Demo-Version leben, dann kannst du dir diese auch downloaden. Allerdings ist der Hexcode auf 2kByte bescränkt. Das reicht aber für viele Projekte aus.
Die RAM-Beschränkung auf 256 bzw. das antiqierte Banking ist bei den 18F...-PICs nicht mehr vorhanden

[RP6conrad]

Meine Erfahrungen mit odometrie sind recht gut. Am ersten sollst du das "E-Compass" programmieren. Da wird einfach die pulsen von L und R encoder gezahlt. Der differenz zwischen beide ist dan eine Mass für die Richtung (ein bische Rechenarbeit wo bei die Breite von Wheelbase wichtig ist). Für die position in 3 D zu wissen, ist ein SIN und COS berechnung notwendig. Nicht ideal für eine µ, aber notwendig. Geht eigenlich auch recht gut mit eine "LOOK_UP" tabelle. Dafur habe ich 256 Bytes in EEPROM reserviert. Die Formule ist einfach : X dif = Abstand*Cos(Alte Winkel - Neue Winkel)/2 Y-dif = Abstand*Sin(dif Winkel)/2.
Diese Berechnung macht du jeden 1 bis 5 cm, und dan X / Y werten addieren.
Ich kann auch mal meine code posten. Ist in C fur eine MEGA32. Robby hat 1.4 mm Weg/Encoderpuls.

[sensemann]

@Thoralf:
danke für den Link. Ich werde mich mal informieren und schauen ob ich damit zurecht komme.


@RP6conrad:
ich weiß irgendwie nich wovon du da redest. du scheinst dich gleich auf irgendwelche include-dateien oder so zu beziehen.
mein problem ist aber momentan dass ich mich auf gar nix beziehen kann und im prinzip alles "von hand" programmieren muss...

und mein jetziges problem ist halt die impulse von den rad-lichtschranken in kombination mit der zeit zu verwerten. ich hatte wie schon gesagt vor gehabt das in array's zu schreiben.

gib mal mehr infos wie dein system aufgebaut ist.

viele grüße, sensemann

[RP6conrad]

Meine Robby hat zwei Antriebsrader mit an jedes Rad ein Encoder. Auflosüng is 1.4 mm/Encoderflanke. Der Auftrag ist ein bestimmtes Parcours abzulegen. In dieses Parcours sind Coladuse zu detectieren und entsprechend dazwischen Slalommen. Dafur nutze ich Sharp IR-sensoren. Mit hilfe von das E-compass und die abgelegte Strecke von jedes Rad ist das machbar. Nach eine Fahrweg von ca 8 meter und eine gasen menge 90° bis 720° Winkel komt er immer wieder auf seine Richtige Ausgangspositionen zuruck. Aber das Speicheren von jeden abgelegte centimeter ist absolut nicht notwendig !! Mein Algoritme sieht aus wie : Fahre gerade aus 2 meter, danach eine 180° Drehung, dan wieder 2 meter zuruck.

[Thoralf]

ich glaube, ich habe verstanden, was RP6 meint.

@sensenmann:
erstmal, ich sende die Odometrie direkt an einen PC und zeichne dort eine Karte über den zurückgelegten Weg.
Wenn das im PIC selbst stattfinden soll, muß man die Aufgabenstellung sehr genau definieren und abschätzen:

-braucht man wirklich aller soundsoviel Zeiteinheiten eine Messung?

-genügt es, bei jeder Kursänderung die Wegdaten und den aktuellen Kurswinkel aufzuzeichnen?

- wieviel Bit sollen die Wegsdatenworte haben? Reichen 8bit Auflösung für jedes delta s ?

- soll die Zeit (Zeitstempel) aufgezeichnet werden?

- sollte man die Daten lieber in einem externen FlashProm aufzeichnen? Beispielprogramme in Assembler gibts im Netz (auch in der Doku zum PIC) genug.

Eine Aufzeichnung in einem Array ist in Wirklichkeit nichts anderes als eine sequentielle Abspeicherung im Speicher. Der Index ergibt sich aus der Datensatzlänge. Ein Beispiel:
Wir speichern die Zeit in sec in 16 bit ab. Dann folgen die Inkremente der 2 Räder = 2x 16 bit. Danach kommt der Kurswinkel mit wiederum 16 bit.
Das macht zusammen 4x 16bit = 64bit
Möchtest du den Daten Satz 21 aufrufen, dann rechnest du einfach Datensatznummer mal Datensatzlänge = 21 x 64 = 1344
=> an der Adresse 1344 steht der 21. Datensatz beginnend mit der Zeit

Bei solchen Datenwortlängen kommt man natürlich schnell über die RAM-Grenze hinaus, selbst bei 8bit-Werten. Da wäre die externe EEPROM-Lösung günstig, weil auch sehr gut erweiterbar.

[sensemann]

hy.

ob man alle soundsoviel Zeiteinheiten eine Messung braucht? ne, eigentlich nicht. so wie ihr das beschrieben habt klingt das einleuchtend, die aufzeichnung nur bei einer richtungsänderung durchzuführen - was aber bei vielen kurvenfahrten (also richtige kurven) dann auch fast immer ist.

der roboter soll halt später in der lage sein von punkt A bis zu punkt B in einem raum zu fahren, ohne dauernd dabei anzuhalten und sich auf der stelle zu drehen. er soll also natürlich eine normale kurve fahren. klappt das bei euren bots?

ich will mir das ganze ja auch nicht unnötig schwer machen. das was ich hier bisher geschrieben habe ist einfach nur mein weg, wie ich das ganze dann umgesetzt hätte. wenn ihr sagt es funktioniert auch so genau genug ist das für mich ok - ihr habt schließlich mehr erfahrungen damit.

die daten von nem pc aufzeichnen zu lassen habe ich hier schon mal vorgeschlagen bekommen. irgendwie gefällt mir die idee immer besser (abgesehen davon dass ich mich da auch noch einarbeiten muss...). dann wäre ja auch eine EEPROM auslagerung überlüssig. womit hast du die pc-seite programmiert? wie lange habt ihr für die gesamte programmentwicklung gebraucht und welche hilfsmittel (oder welche vorhandenen teile) habt ihr dabei verwendet?

viele grüße

[Thoralf]

im großen und ganzen klappt die Lokalisierung via Odometrie. Berücksichtigen sollte man Schlupf der Räder, schlechte Kalibrierung der Radsensoren.
Zur Kompensation sollte man unbedingt ein 2. unabhängiges Verfahren, z.B. über IR- und US-Sensoren vorsehen.Beispiele gibts hier ja genug.

Bei mir ist auf einem der Roboter lediglich ein Controller, der alle Sensoren ausliest und über Funk (von Roboterteile.de) an den PC schickt.
Ein Visual Basic-Programm liest die Datensätze an der COM1 und trägt die Positione des Robo in eine Raumkarte ein.. Das funktioniert ganz gut. Nun will ich mit einem 2. Verfahren die Position via Kamera triangulieren und immer mal Fehlanzeigen korrigieren.